We are having application which load our custom DLLs (these DLLs are implementing some interface) on runtime from the root of the application and execute a method through reflection.
If custom DLL have to read some value from config files then we have to copy these config settings into app.config file of the main application.
Is there any way where each custom DLL will have own configuring file named .config and read its configuration settings from this files itself.
If you're on .NET 2.0 or higher, you can manually tell the Configuration system to load the settings from any config file you want.
ExeConfigurationFileMap exeMap = new ExeConfigurationFileMap();
exeMap.ExeConfigFilename = "C:\Application\Default.config";
Configuration exeConfig = ConfigurationManager.OpenMappedExeConfiguration(exeMap, ConfigurationUserLevel.None);
Now you have your custom "Config" object and you can party on it! :-) Load a whole section by calling exeConfig.GetSection() or whatever you like.
Also check out this excellent three-part series on .NET 2.0 configuration system on CodeProject - highly recommended!
Unraveling the mysteries of .NET 2.0 configuration
Decoding the mysteries of .NET 2.0 configuration
Cracking the mysteries of .NET 2.0 configuration
Marc
Load your DLL into a new AppDomain and set the AppDomainSetup.ConfigurationFile. This will let you create a separate config file for each custom DLL.
I was certain there is a way to do this in the framework, just can't remember off the top of my head. What you're looking for is Per-Assembly configuration files, I remember reading an article about this Per Assembly Configuration Files
Related
To migrate an application I want to continue using the plain old settings that still come along with .Net5 (App.Config, Settings.settings and so on).
I need a simple built in solution without additional dependencies.
The proposed way seems to be appsettings.json or similar.
For that to use with WPF you need to add some additonal dependencies which bloat the project when
publishing it as single exe (not self contained). It is over-the-top for simple applications.
I followed the steps here:
Equivalent to UserSettings / ApplicationSettings in WPF dotnet core
The accepted answer from Alexander works for a normal exe built.
These are the generated files
MyApp.dll
MyApp.dll.config
MyApp.exe
Modifying "MyApp.dll.config" with an editor directly reflects the changed data in the code.
MessageBox.Show(Settings.Default.SomeConfigValue);
The used config file can be displayed using
var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
MessageBox.Show(config.FilePath);
It displays
C:\Projekte\MyApp\MyApp\bin\Debug\net5.0-windows\MyApp.dll.config
Unfortunately this fails for single exe
These are the generated files (in publish folder)
MyApp.dll.config
MyApp.exe
Modifying "MyApp.dll.config" or "MyApp.exe.config" has no effect. The file does not seem to be used by the framework.
Above messagebox now shows
C:\Projekte\MyApp\Publish<Unknown>.config
How to get the built-in configuration system work with single exe?
I have two applications refering to a dll (A.dll). The dlls are refernced from both application's local directories. Application1 use Settings.Default to store string to the dll (A.dll). Will those strigs that are saved to settings of A.Dll by Applciation1 be accessible to Application2?
As far as I'm aware, each application setting should have it's own settings file. Furthermore, if you have used a user-scoped settings, then each user from each application will have their own settings files.
You can find full details from the following links:
Using Settings in C#
Application Settings Overview
We use the .NET resource manager to localize our Silverlight application and want to embed the satellite assemblies for the german language ("de") into the XAP file. Therefor, we set the neutral language to "en" and added "de" to the list of supported languages in the csproj file. This works fine, when we build the project locally. If we build the Silverlight solution with MSBuild (TFS), Silverlight will try to fetch the satellite assemblies with HTTP requests from /ClientBin/de/*.dll instead of taking those files embeded into the XAP (which do exist). Because the webserver returns 404 error codes for the non existent files, Silverlight crashes with an initialization error.
It turned out that if we remove a custom TFS build activity manipulating the assembly info code files, the Silverlight applications works as expected. Strangely, after re-enabling the activity the compiled XAP application still works (verified for two different build definitions working on seperate branches). The custom activity manipulates the assembly attributes AssemblyConfiguration, AssemblyCompany, AssemblyProduct, AssemblyCopyright, AssemblyTrademark, AssemblyVersion, and AssemblyFileVersion.
Some additional hints:
The custom activity will change the assembly info files before any compilation is done
Compiling the manipulated sources with Visual Studio will build a working XAP
The content of the XAP files (working and not working) is equal (nearly same sizes, no difference in manifest file)
The resource manager is instantiated using ResourceManager("Resource", Assembly.GetExecutingAssembly())
My questions are:
Why does Silverlight try to fetch those satellite assemblies from /ClientBin/de/ instead of just using those in the XAP file?
What kind of attribute in the assembly info file could cause such a behavior?
Why does re-enabling the versioning activity not break the XAP again?
And here's the solution: We use a tool named "Total Commander" for editing a file in the generated XAP to adjust the URL the (generic) client connects to. Since we added the localization dlls, editing the XAP with the Total Commander will lead to the behavior described above. If we manipulate the XAP with WinRAR or the internal Windows archive manager, all works as expected.
Edit: After comparing the XAP files we found, that Total Commander uses the backslash (\) to seperate directories, whereas WinRAR and the Silverlight Tools use slashes (/). It seems that we discovered a hidden Silverlight feature here ;-)
I've created a Windows Forms (C#) application called "Image Processing". It uses many external dlls so I decided to use ILMerge to merge all of them into one exe file and it worked. But today I've localized my application. After building I had 3 new folders in Debug folder: "en-US", "ru-RU", "uk-UA" with one dll with the same name "ImageProcessing.resources.dll". So I included all of them in a ILMerge command:
ILMerge.exe /t:winexe /out:ImageProcessingRelease.exe ImageProcessing.exe AForge.dll AForge.Imaging.dll AForge.Math.dll DevExpress.Data.v10.2.dll DevExpress.Utils.v10.2.dll DevExpress.XtraBars.v10.2.dll DevExpress.XtraEditors.v10.2.dll FreeImageNET.dll uk-UA\ImageProcessing.resources.dll ru-RU\ImageProcessing.resources.dll en-US\ImageProcessing.resources.dll
My program stores language locale in settings. After merging I can't change language, but settings are changing.
I don't know what else I can include here for more details so tell me please what.
The answer is simple. ILMerge is not suitable in this case, as .NET Framework relies on the folder structure to determine which resource file to use.
It is meaningless to combine assemblies in that way, and some third party assembly vendor's end user license does not permit you to merge their product with your own assemblies.
I don't quite understand how Silverlight code works within the browser. Are the assemblies downloaded to the client machine? Is there any chance of the code getting decompiled using Reflector or some similar tool? If so, what options does one have to protect the code? Do .net obfuscators work with Silverlight?
Whenever you are in a web browser, all client side code is downloaded to the machine and can be examined by the user. This goes for Javascript, Flash, and Silverlight.
If you have proprietary code that absolutely must be hidden then you need to put it on the server and expose an API that the clients can call to show information to the user.
To view a Silverlight application the client download a .xap file that contains the dll and one configuration xml and optional resources. The dll contains compiled c# code that runs in a Silverlight runtime in client machine. Silverlight runtime is basically a subset of complete .net runtime. So the point is user gets the code in dll and then can use tools to get original source code. So at most you can do is obfuscation. Still for very critical code that should not be the option. You can use some other way (WCF or other webservices to hide some part of your code may be) if it shouts your need.
If you want to see just how easy it is to look at the code in a silverlight app just run SilverlightSpylink text by FirstFloor. As long as your have .NET Reflector installed you will be able to see (as you interact with the app) all the source code including the xaml files.
Since the code does get downloaded to the client (and even trying to prevent it with pragma no-cache won't work since they can hit the URL) you will need to protect your code by keeping important logic on the server.
If your afraid some one will steal your intellectual property and that law is not enough, Then you will need to obfuscate your code. But I would not call that protection per say but a deterrent to the casual reverse engineer.
Putting a pragma -No Cache- will prevent the .xap from being stored on the machine, instead it will be streamed by the Silverlight plugin. Without the pragma the .xap file is stored in the temp internet files.
Putting the application on a page on https will further protect the transmition of the .xap
If possible require authentication to view the web page / .xap file (thanks Joel)
Emrah,
Yes obfuscation is possible for SL application.
Yes, Silverlight xap files are nothing but zip files with your assemblies in them, so they do need protection via obfuscation. Give Crypto Obfuscator a try - it directly obfuscates xap files, it can also obfuscate XAML files in your assemblies by renaming class references, stripping comments, whitespace, newlines, etc