Search Results

Search found 15 results on 1 pages for 'strongname'.

Page 1/1 | 1 

  • Strong Naming an assembly using command line compile

    - by David
    I am trying to use NAnt in order to compile and sign an assembly using the vbc compiler. I have a project set up and am able to successfully sign the assembly compiling with VS2010. When I try to sign it using the command line I get this error: vbc : error BC30140: Error creating assembly manifest: Error signing assembly -- The parameter is incorrect. I even created a trivially simple app (just an assemblyinfo.vb file) that will not compile and sign using vbc.exe What am I doing wrong? here is my assemblyinfo.vb: Option Strict Off Option Explicit On Imports System Imports System.Reflection <Assembly: AssemblyVersionAttribute("2010.05.18.0918"), _ Assembly: AssemblyCopyrightAttribute("Copyright © Patient First 2007"), _ Assembly: AssemblyCompanyAttribute("Patient First, Inc."), _ Assembly: AssemblyProductAttribute("Patient First Framework"), _ Assembly: AssemblyDelaySign(false), _ Assembly: AssemblyKeyFile("test.pfx"), _ Assembly: AssemblyTitleAttribute("PatientFirst.Framework")> test.pfx is located in the same folder as assemblyinfo.vb Here is how I am trying to compile it: vbc /target:library /verbose assemblyinfo.vb I also tried using vbc /target:library /verbose assemblyinfo.vb /keyfile:test.pfx and tried using /keyfile parameter without the AssemblyDelaySign and AssemblyKeyFile attributes If I remove the AssemblyDelaySign and AssemblyKeyFile attributes and leave off the /keyfile command line parameter it compiles fine. What is the correct way to do this with vbc? --EDIT: I have found that MSBuild also does not like having the AssemblyKeyFile attribute as I have defined it in the AssemblyInfo.vb, it gives the same failure message. So the only way I can currently get this to build correctly is to set properties on the project to tell it which key file to use and to sign the assembly.

    Read the article

  • VS 2010 Profiling Problem with Signed Assemblies

    - by Binder
    I have a website that uses AjaxControlToolkit.dll and Log4Net.dll; When I try to run the performance profiling tool in VS 2010 on it it gives me the following warnings "AjaxControlToolkit.dll is signed and instrumenting it will invalidate its signature. If you proceed without a post-instrument event to re-sign the binary it may not load correctly". Now, if I choose the option to continue without re-signing the profiling starts but the assembly doesn't load and gives an ASP.NET exception.

    Read the article

  • Strong name, Manifest, and Code Signing

    - by Brian
    What order should these be done in? I'm doing this from the command prompt for a .Net app. I was able to do just strong name and code signing successfully, but when I tried all three, it doesn't look like it worked (== Vista still trying to run the app with elevated privileges resulting in a prompt, though I set the requestedexecutionlevel at asInvoker) Thanks in advance

    Read the article

  • Strong name validation failed on VB.NET Assembly

    - by Matt Baker
    I have a VB.Net 1.1 application works just fine after compiling in Visual Studio. However, I want to use ILMerge to combine all the referenced assemblies into a single executable just to make it easier to move around. After I send it through ILMerge and try to run it I get the error "Strong name validation failed for .exe" ..... But none of my stuff is strong named! I saw this post here: http://stackoverflow.com/questions/403731/strong-name-validation-failed and tried running it through 'sn.exe -Vr .exe' but that gives me this error: ".exe does not represent a strongly named assembly" Has anyone else had this problem before? How do I fix it?

    Read the article

  • How do I specify a keys password with MSBuild for the purpose of using Hudson?

    - by Brett Ryan
    We have just setup our hudson server to build .NET projects which seems to be working fine, however for projects that require a password when signing the assemblies I can not figure out how to tell hudson what the password is? For us the password is asked the first time a developer checks out the source code and they open with visual studio, how is this stored? Can we just place a secret file somewhere on the server?

    Read the article

  • Validate Strong Name of Running Assembly

    - by Kyle Rozendo
    Is it possible for one to check the strong name of a .NET application that is already currently running separately from your own running applications process? EDIT: For clarification, a solution that does not require a hard coded path to the executing assembly would be the most ideal solution. EDIT #2: Is there any way to do this without using reflection?

    Read the article

  • Signing 3rd Party Assemblies leads to them turnign invisible!

    - by Andrew
    Hi All, I followed OJ's instructions here This allowed me to successfully breakdown, then rebuild and sign some 3rd party DLLs. Here's what I did: Dissassembled Old.dll Rebuild and signed as New.dll (using the same *.snk that my VS2005 proj is signed with) Removed all references in my proj to Old.dll and added references to New.dll Replaced 'Imports Old.dll' with 'Imports New.dll' this final step fails. VS2005 won't recognise my New.dll Any clues?

    Read the article

  • Creating a Sandboxed Instance

    - by Ricardo Peres
    In .NET 4.0 the policy APIs have changed a bit. Here's how you can create a sandboxed instance of a type, which must inherit from MarshalByRefObject: static T CreateRestrictedType<T>(SecurityZone zone, params Assembly [] fullTrustAssemblies) where T : MarshalByRefObject, new() { return(CreateRestrictedType<T>(zone, fullTrustAssemblies, new IPermission [0]); } static T CreateRestrictedType<T>(SecurityZone zone, params IPermission [] additionalPermissions) where T : MarshalByRefObject, new() { return(CreateRestrictedType<T>(zone, new Assembly [0], additionalPermissions); } static T CreateRestrictedType<T>(SecurityZone zone, Assembly [] fullTrustAssemblies, IPermission [] additionalPermissions) where T : MarshalByRefObject, new() { Evidence evidence = new Evidence(); evidence.AddHostEvidence(new Zone(zone)); PermissionSet evidencePermissionSet = SecurityManager.GetStandardSandbox(evidence); foreach (IPermission permission in additionalPermissions ?? new IPermission[ 0 ]) { evidencePermissionSet.AddPermission(permission); } StrongName [] strongNames = (fullTrustAssemblies ?? new Assembly[0]).Select(a = a.Evidence.GetHostEvidence<StrongName>()).ToArray(); AppDomainSetup adSetup = new AppDomainSetup(); adSetup.ApplicationBase = Path.GetDirectoryName(typeof(T).Assembly.Location); AppDomain newDomain = AppDomain.CreateDomain("Sandbox", evidence, adSetup, evidencePermissionSet, strongNames); ObjectHandle handle = Activator.CreateInstanceFrom(newDomain, typeof(T).Assembly.ManifestModule.FullyQualifiedName, typeof(T).FullName); return (handle.Unwrap() as T); } SyntaxHighlighter.config.clipboardSwf = 'http://alexgorbatchev.com/pub/sh/2.0.320/scripts/clipboard.swf'; SyntaxHighlighter.brushes.CSharp.aliases = ['c#', 'c-sharp', 'csharp']; SyntaxHighlighter.all();

    Read the article

  • .NET Security Part 2

    - by Simon Cooper
    So, how do you create partial-trust appdomains? Where do you come across them? There are two main situations in which your assembly runs as partially-trusted using the Microsoft .NET stack: Creating a CLR assembly in SQL Server with anything other than the UNSAFE permission set. The permissions available in each permission set are given here. Loading an assembly in ASP.NET in any trust level other than Full. Information on ASP.NET trust levels can be found here. You can configure the specific permissions available to assemblies using ASP.NET policy files. Alternatively, you can create your own partially-trusted appdomain in code and directly control the permissions and the full-trust API available to the assemblies you load into the appdomain. This is the scenario I’ll be concentrating on in this post. Creating a partially-trusted appdomain There is a single overload of AppDomain.CreateDomain that allows you to specify the permissions granted to assemblies in that appdomain – this one. This is the only call that allows you to specify a PermissionSet for the domain. All the other calls simply use the permissions of the calling code. If the permissions are restricted, then the resulting appdomain is referred to as a sandboxed domain. There are three things you need to create a sandboxed domain: The specific permissions granted to all assemblies in the domain. The application base (aka working directory) of the domain. The list of assemblies that have full-trust if they are loaded into the sandboxed domain. The third item is what allows us to have a fully-trusted API that is callable by partially-trusted code. I’ll be looking at the details of this in a later post. Granting permissions to the appdomain Firstly, the permissions granted to the appdomain. This is encapsulated in a PermissionSet object, initialized either with no permissions or full-trust permissions. For sandboxed appdomains, the PermissionSet is initialized with no permissions, then you add permissions you want assemblies loaded into that appdomain to have by default: PermissionSet restrictedPerms = new PermissionSet(PermissionState.None); // all assemblies need Execution permission to run at all restrictedPerms.AddPermission( new SecurityPermission(SecurityPermissionFlag.Execution)); // grant general read access to C:\config.xml restrictedPerms.AddPermission( new FileIOPermission(FileIOPermissionAccess.Read, @"C:\config.xml")); // grant permission to perform DNS lookups restrictedPerms.AddPermission( new DnsPermission(PermissionState.Unrestricted)); It’s important to point out that the permissions granted to an appdomain, and so to all assemblies loaded into that appdomain, are usable without needing to go through any SafeCritical code (see my last post if you’re unsure what SafeCritical code is). That is, partially-trusted code loaded into an appdomain with the above permissions (and so running under the Transparent security level) is able to create and manipulate a FileStream object to read from C:\config.xml directly. It is only for operations requiring permissions that are not granted to the appdomain that partially-trusted code is required to call a SafeCritical method that then asserts the missing permissions and performs the operation safely on behalf of the partially-trusted code. The application base of the domain This is simply set as a property on an AppDomainSetup object, and is used as the default directory assemblies are loaded from: AppDomainSetup appDomainSetup = new AppDomainSetup { ApplicationBase = @"C:\temp\sandbox", }; If you’ve read the documentation around sandboxed appdomains, you’ll notice that it mentions a security hole if this parameter is set correctly. I’ll be looking at this, and other pitfalls, that will break the sandbox when using sandboxed appdomains, in a later post. Full-trust assemblies in the appdomain Finally, we need the strong names of the assemblies that, when loaded into the appdomain, will be run as full-trust, irregardless of the permissions specified on the appdomain. These assemblies will contain methods and classes decorated with SafeCritical and Critical attributes. I’ll be covering the details of creating full-trust APIs for partial-trust appdomains in a later post. This is how you get the strongnames of an assembly to be executed as full-trust in the sandbox: // get the Assembly object for the assembly Assembly assemblyWithApi = ... // get the StrongName from the assembly's collection of evidence StrongName apiStrongName = assemblyWithApi.Evidence.GetHostEvidence<StrongName>(); Creating the sandboxed appdomain So, putting these three together, you create the appdomain like so: AppDomain sandbox = AppDomain.CreateDomain( "Sandbox", null, appDomainSetup, restrictedPerms, apiStrongName); You can then load and execute assemblies in this appdomain like any other. For example, to load an assembly into the appdomain and get an instance of the Sandboxed.Entrypoint class, implementing IEntrypoint, you do this: IEntrypoint o = (IEntrypoint)sandbox.CreateInstanceFromAndUnwrap( "C:\temp\sandbox\SandboxedAssembly.dll", "Sandboxed.Entrypoint"); // call method the Execute method on this object within the sandbox o.Execute(); The second parameter to CreateDomain is for security evidence used in the appdomain. This was a feature of the .NET 2 security model, and has been (mostly) obsoleted in the .NET 4 model. Unless the evidence is needed elsewhere (eg. isolated storage), you can pass in null for this parameter. Conclusion That’s the basics of sandboxed appdomains. The most important object is the PermissionSet that defines the permissions available to assemblies running in the appdomain; it is this object that defines the appdomain as full or partial-trust. The appdomain also needs a default directory used for assembly lookups as the ApplicationBase parameter, and you can specify an optional list of the strongnames of assemblies that will be given full-trust permissions if they are loaded into the sandboxed appdomain. Next time, I’ll be looking closer at full-trust assemblies running in a sandboxed appdomain, and what you need to do to make an API available to partial-trust code.

    Read the article

  • .NET Security Part 3

    - by Simon Cooper
    You write a security-related application that allows addins to be used. These addins (as dlls) can be downloaded from anywhere, and, if allowed to run full-trust, could open a security hole in your application. So you want to restrict what the addin dlls can do, using a sandboxed appdomain, as explained in my previous posts. But there needs to be an interaction between the code running in the sandbox and the code that created the sandbox, so the sandboxed code can control or react to things that happen in the controlling application. Sandboxed code needs to be able to call code outside the sandbox. Now, there are various methods of allowing cross-appdomain calls, the two main ones being .NET Remoting with MarshalByRefObject, and WCF named pipes. I’m not going to cover the details of setting up such mechanisms here, or which you should choose for your specific situation; there are plenty of blogs and tutorials covering such issues elsewhere. What I’m going to concentrate on here is the more general problem of running fully-trusted code within a sandbox, which is required in most methods of app-domain communication and control. Defining assemblies as fully-trusted In my last post, I mentioned that when you create a sandboxed appdomain, you can pass in a list of assembly strongnames that run as full-trust within the appdomain: // get the Assembly object for the assembly Assembly assemblyWithApi = ... // get the StrongName from the assembly's collection of evidence StrongName apiStrongName = assemblyWithApi.Evidence.GetHostEvidence<StrongName>(); // create the sandbox AppDomain sandbox = AppDomain.CreateDomain( "Sandbox", null, appDomainSetup, restrictedPerms, apiStrongName); Any assembly that is loaded into the sandbox with a strong name the same as one in the list of full-trust strong names is unconditionally given full-trust permissions within the sandbox, irregardless of permissions and sandbox setup. This is very powerful! You should only use this for assemblies that you trust as much as the code creating the sandbox. So now you have a class that you want the sandboxed code to call: // within assemblyWithApi public class MyApi { public static void MethodToDoThings() { ... } } // within the sandboxed dll public class UntrustedSandboxedClass { public void DodgyMethod() { ... MyApi.MethodToDoThings(); ... } } However, if you try to do this, you get quite an ugly exception: MethodAccessException: Attempt by security transparent method ‘UntrustedSandboxedClass.DodgyMethod()’ to access security critical method ‘MyApi.MethodToDoThings()’ failed. Security transparency, which I covered in my first post in the series, has entered the picture. Partially-trusted code runs at the Transparent security level, fully-trusted code runs at the Critical security level, and Transparent code cannot under any circumstances call Critical code. Security transparency and AllowPartiallyTrustedCallersAttribute So the solution is easy, right? Make MethodToDoThings SafeCritical, then the transparent code running in the sandbox can call the api: [SecuritySafeCritical] public static void MethodToDoThings() { ... } However, this doesn’t solve the problem. When you try again, exactly the same exception is thrown; MethodToDoThings is still running as Critical code. What’s going on? By default, a fully-trusted assembly always runs Critical code, irregardless of any security attributes on its types and methods. This is because it may not have been designed in a secure way when called from transparent code – as we’ll see in the next post, it is easy to open a security hole despite all the security protections .NET 4 offers. When exposing an assembly to be called from partially-trusted code, the entire assembly needs a security audit to decide what should be transparent, safe critical, or critical, and close any potential security holes. This is where AllowPartiallyTrustedCallersAttribute (APTCA) comes in. Without this attribute, fully-trusted assemblies run Critical code, and partially-trusted assemblies run Transparent code. When this attribute is applied to an assembly, it confirms that the assembly has had a full security audit, and it is safe to be called from untrusted code. All code in that assembly runs as Transparent, but SecurityCriticalAttribute and SecuritySafeCriticalAttribute can be applied to individual types and methods to make those run at the Critical or SafeCritical levels, with all the restrictions that entails. So, to allow the sandboxed assembly to call the full-trust API assembly, simply add APCTA to the API assembly: [assembly: AllowPartiallyTrustedCallers] and everything works as you expect. The sandboxed dll can call your API dll, and from there communicate with the rest of the application. Conclusion That’s the basics of running a full-trust assembly in a sandboxed appdomain, and allowing a sandboxed assembly to access it. The key is AllowPartiallyTrustedCallersAttribute, which is what lets partially-trusted code call a fully-trusted assembly. However, an assembly with APTCA applied to it means that you have run a full security audit of every type and member in the assembly. If you don’t, then you could inadvertently open a security hole. I’ll be looking at ways this can happen in my next post.

    Read the article

  • WPF: isolated storage file path too long

    - by user342961
    Hi, I'm deploying my WPF app with ClickOnce. When developing locally in Visual Studio, I store files in the isolated storage by calling IsolatedStorageFile.GetUserStoreForDomain(). This works just fine and the generated path is C:\Users\Frederik\AppData\Local\IsolatedStorage\phqduaro.crw\hux3pljr.cnx\StrongName.kkulk3wafjkvclxpwvxmpvslqqwckuh0\Publisher.ui0lr4tpq53mz2v2c0uqx21xze0w22gq\Files\FilerefData\-581750116 (189 chars) But when I deploy my app with ClickOnce, the generated path becomes too long, resulting in a DirectoryNotFoundException when creating the isolated storage directory. The generated path with ClickOnce is: C:\Users\Frederik\AppData\Local\Apps\2.0\Data\OQ0LNXJT.R5V\8539ABHC.ODN\exqu..tion_e07264ceafd7486e_0001.0000_b8f01b38216164a0\Data\StrongName.wy0cojdd3mpvq45404l3gxdklugoanvi\Publisher.ui0lr4tpq53mz2v2c0uqx21xze0w22gq\Files\FilerefData\-581750116 (247 chars) When I browse the folders all but the last directory of the path exists. Then when trying to create a folder at this location windows tells me I can't create a directory because the resulting path name will be too long. How can I shorten the path generated by the IsolatedStorage?

    Read the article

  • SecurityException in Sandboxed AppDomain

    - by Galen
    I'm attempting to use C# as a scripting language using CSharpCodeProvider (using VS2010 and .NET 4.0). I want the scripts to be run in a restricted AppDomain with minimal permissions. Currently, I'm getting an exception while trying to instantiate a class in the AppDomain (The call to CreateInstanceAndUnwrap()). Here is some simplified code that reproduces the exception: using System; using System.Collections.Generic; using Microsoft.CSharp; using System.CodeDom; using System.CodeDom.Compiler; using System.Security; using System.Security.Policy; using System.Security.Permissions; using System.Reflection; using System.Runtime.Remoting; namespace ConsoleApp { class Program { static void Main(string[] args) { // set permissions PermissionSet permissions = new PermissionSet(PermissionState.None); permissions.AddPermission(new SecurityPermission( SecurityPermissionFlag.Execution)); AppDomainSetup adSetup = new AppDomainSetup(); adSetup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; //Create a list of fully trusted assemblies Assembly[] asms = AppDomain.CurrentDomain.GetAssemblies(); List<StrongName> sns = new List<StrongName>(); for (int x = 0; x < asms.Length; x++) { StrongName sn = asms[x].Evidence.GetHostEvidence<StrongName>(); if (sn != null && sns.Contains(sn) == false) sns.Add(sn); } //this includes: "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" AppDomain domain = AppDomain.CreateDomain("NewAppDomain", AppDomain.CurrentDomain.Evidence, adSetup, permissions);//, sns);//, sn4, sn, sn2, sn3); try { String asmName = Assembly.GetExecutingAssembly().FullName; String typeName = typeof(ConsoleApp.ScriptRunner).FullName; //Throws exception here ScriptRunner scriptRunner = domain.CreateInstanceAndUnwrap(asmName, typeName) as ScriptRunner; } catch (SecurityException se) { System.Diagnostics.Debug.WriteLine(se.Message); } catch (Exception ex) { System.Diagnostics.Debug.WriteLine(ex.Message); } } } public class ScriptRunner : MarshalByRefObject { public ScriptRunner() { //A breakpoint placed here is never reached. CompilerParameters param; param = new CompilerParameters(); param.CompilerOptions = ""; param.GenerateExecutable = false; param.GenerateInMemory = true; param.IncludeDebugInformation = false; // C# compiler CSharpCodeProvider codeProvider = new CSharpCodeProvider(); CompilerResults results = codeProvider.CompileAssemblyFromFile(param, "Danger.cs"); } } } The exception is being thrown from mscorlib and it is a System.Reflection.TargetInvocationException that has an inner System.Security.SecurityException. Here is the exception: System.Reflection.TargetInvocationException was unhandled Message=Exception has been thrown by the target of an invocation. Source=mscorlib StackTrace: at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache) at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean skipCheckThis, Boolean fillCache) at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark) at System.Activator.CreateInstance(String assemblyName, String typeName) at System.AppDomain.CreateInstance(String assemblyName, String typeName) at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName) at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName) at ConsoleApp.Program.Main(String[] args) in C:\Documents and Settings\NaultyCS\my documents\visual studio 2010\Projects\ConsoleApplication4\ConsoleApplication4\Program.cs:line 46 at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() InnerException: System.Security.SecurityException Message=Request failed. Source=ConsoleApplication4 GrantedSet=<PermissionSet class="System.Security.PermissionSet" version="1"> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Execution"/> </PermissionSet> PermissionState=<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true"/> RefusedSet="" Url=file:///C:/Documents and Settings/NaultyCS/my documents/visual studio 2010/Projects/ConsoleApplication4/ConsoleApplication4/bin/Debug/ConsoleApplication4.EXE StackTrace: at ConsoleApp.ScriptRunner..ctor() InnerException: So it appears to me that mscorlib is demanding full trust. I've added it as a fully trusted assembly, but it has no effect. What am I doing wrong here?

    Read the article

  • Interpreting w3wp.exe thread-infos, does mscorwks.dll!StrongNameErrorInfo+0x7688 has a negative impa

    - by Robert
    I am trying to interpret the meaning of "mscorwks.dll!StrongNameErrorInfo+0x7688". I guess it means, that the assembly loaded by the mscorworks.dll has no StrongName? If yes, does this have any negative impact for a web application? Is it safe to assume that the thread count of 107 means, that web application has needed a maximum of 107 concurrent threads to handle incoming requests?

    Read the article

  • Isolated storage misunderstand

    - by Costa
    Hi this is a discussion between me and me to understand isolated storage issue. can you help me to convince me about isolated storage!! This is a code written in windows form app (reader) that read the isolated storage of another win form app (writer) which is signed. where is the security if the reader can read the writer's file, I thought only signed code can access the file! If all .Net applications born equal and have all permissions to access Isolated storage, where is the security then? If I can install and run Exe from isolated storage, why I don't install a virus and run it, I am trusted to access this area. but the virus or what ever will not be trusted to access the rest of file system, it only can access the memory, and this is dangerous enough. I cannot see any difference between using app data folder to save the state and using isolated storage except a long nasty path!! I want to try give low trust to Reader code and retest, but they said "Isolated storage is actually created for giving low trusted application the right to save its state". Reader code: private void button1_Click(object sender, EventArgs e) { String path = @"C:\Documents and Settings\All Users\Application Data\IsolatedStorage\efv5cmbz.ewt\2ehuny0c.qvv\StrongName.5v3airc2lkv0onfrhsm2h3uiio35oarw\AssemFiles\toto12\ABC.txt"; StreamReader reader = new StreamReader(path); var test = reader.ReadLine(); reader.Close(); } Writer: private void button1_Click(object sender, EventArgs e) { IsolatedStorageFile isolatedFile = IsolatedStorageFile.GetMachineStoreForAssembly(); isolatedFile.CreateDirectory("toto12"); IsolatedStorageFileStream isolatedStorage = new IsolatedStorageFileStream(@"toto12\ABC.txt", System.IO.FileMode.Create, isolatedFile); StreamWriter writer = new StreamWriter(isolatedStorage); writer.WriteLine("Ana 2akol we ashrab kai a3eesh wa akbora"); writer.Close(); writer.Dispose(); }

    Read the article

1