. NET code controls the location of Privatebinpath and ConfigurationFile

. NET WinForm program sometimes annoying is that in the execution directory is always a lot of DLLs, configuration files, at least is the following, many times afraid there are forty or fifty bar ..., the class library in its own program, the third-party class library ... Loading together makes people feel a mess, very uncomfortable. In the next although there is no cleanliness in personal hygiene, but the application of this look does not have a bit of tolerance, is to endure what is not to endure ah!

Processing these DLLs is still relatively simple, configuration files can be configured. First, the DLLs are categorized, Core, Module, misc, and so on, and then add these directory names to App. Config. Such as:

<runtime>  <assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1">    <probing privatepath="Castle; Core; Module; UI; Misc; "/>  </assemblyBinding></runtime>

Well, it looks more comfortable now. Slow...... In the home directory, out of our application exe executable file, there is an exception, App. config ... How much is still a bit uncomfortable, how to do? Let's build a data directory and move the config file in! Just do it, we'll move the app. config to the subordinate directory, happy Ah, see if the program can run? The cup has happened and the program runs without reaction ... With VS debugging, it was found that the type in the other class library could not be caused. Also, we just added a privatepath to the config file, and now we have moved the file, how can I load it into a DLL in another directory?

Knowing the reason, of course, is good to solve. It is said that the location of the configuration file can be specified. The Appdomainsetup.configuraitonfile attribute refers to this. Let's try ...

Analysis:

The path to change the config is, of course, before using Config, and the sooner the better ... Where is it earlier? Well, the main function, the entrance to the program is a good choice ...

 static  class   program{ ///     <summary>  ///  The main entry point of the application.  /// </SUMMARY>   [STAThread]  static  void
     Main () {AppDomain.CurrentDomain.SetupInformation.ConfigurationFile  =  " data\myapp.config   "         ;    Application.Run ( new   Myappform ()); }}

Good, compile, full of confidence to run the program again, but the cup once again ah happened, still no response ...

...... In this debugging, surprised to find that this property setting is completely ineffective, after the statement execution, the property value is still the default value. So check the documentation ah, Baidu Ah, Google Ah ~ finally know the correct way to set CONFIG.

AppDomain.CurrentDomain.SetData ("app_config_file", Path);

Well, this one ... is not Microsoft in harm ... Okay, stop complaining and keep working. Well, see, the location of the config file takes effect, pointing to the location of our reservation, but ... Cup with no surprises happened again ... DLL still can't load!

Although I have seen the Privatebinpath property in the AppDomainSetup, but I am a little excited to feel nothing, should be similar to the previous results!

Think about the process of running the program, Privatebinpath is a property in AppDomain.Current.SetupInformation, and this property only takes effect when appdomain.create, and after the AppDomain has been established change the path of config to set this value, you should It's not going to work. It seems to have to be set in code. But how to do it?

Close the door and put reflector! Well, let's look at the internal situation of the AppDomain. otherwise! Setupinforamtion is just a copy of its internal configuration, which explains why changing a property is not effective!

 Public appdomainsetup setupinformation{    get    {        returnnew AppDomainSetup (Thistrue);}    }

It doesn't seem to be a good way to use the ultimate means! Reflection! Change the inner field to achieve our goal! Examine the following code carefully and discover that the setup information inside the AppDomain is stored in a funsionstore internal attribute. All right, let's get this out of here!

AppDomain.CurrentDomain.SetData ("private_binpath""Castle; Core; Module; UI; Misc; " ); AppDomain.CurrentDomain.SetData ("binpath_probe_only""Castle; Core; Module; UI; Misc; ");

This code does change the value of the AppDomain.CurrentDomain.SetupInformation.PrivateBinPath, but the run discovery type is still not loaded! There may be a refrefshconfiguraiton or Updatecache-like method in the interior to refresh! Continue to find AH find ~ finally found. is a static extern method. Oh...... This is easy, look at the code!

During the debugging process, we also found that the main method is not the best place, so we put the code in the program's static construction method, this is in addition to the static field of the earliest starting point.

StaticProgram () {AppDomain.CurrentDomain.SetData ("Private_binpath","Castle; Core; Module; UI; Misc;"); AppDomain.CurrentDomain.SetData ("binpath_probe_only","Castle; Core; Module; UI; Misc;"); varm =typeof(AppDomainSetup). GetMethod ("Updatecontextproperty", BindingFlags.NonPublic |bindingflags.static); varFunsion =typeof(AppDomain). GetMethod ("Getfusioncontext", BindingFlags.NonPublic |bindingflags.instance); M.invoke (NULL,New Object[] {funsion. Invoke (Appdomain.currentdomain,NULL),"Private_binpath","Castle; Core; Module; UI; Misc;" });}

Well, can't wait to compile, run! Wow! No surprise, the program is normal, and then look at the application directory, only a clean EXE file exists, really cool to the extreme ~

Tell you, exe file on one, I can! Ha ha!

Finally, if there is a static field in the program, do not define it as the type of the other class library, because this time we have not implemented the above method, will be unable to find the type and error Oh ~

. NET code controls the location of Privatebinpath and ConfigurationFile