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 ;-)
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?
In the past I've used the solution outlined in the following URL to avoid multiple downloads of 3rd party dlls in modular Silverlight applications:
How to optimize the size of silverlight XAP file by removing common files?
However I am working on a Visual Studio 2010/Silverlight 5 solution application where this is not working.
I have a PRISM module let's call it Parent1.csproj that has no references to my 3rdParty dlls but it does have a reference to two other project files which reference the 3rdParty dlls child1.csproj and child2.csproj
child1.csproj and child2.csproj both have "Copy Local" set to false for 3rdParty.dlls but in spite of this the .xap file for Parent1.csproj contains the 3rd party dlls.
If I set child1.csproj and child2.csproj references in the Parent1.csproj file with "Copy Local" set to false then I get a dramatically reduced xap file with no 3rd party dlls but also none of the other code in the child projects that I actually need to be able to run.
It seems as if included project files get their "Copy Local" setting ignored and use the parent "Copy Local" setting instead, and there's no way for me to exclude those 3rdParty.dlls
Have I missed something subtle here? Is there some other way I can avoid downloading those 3rdParty.dlls in multiple modules when the shell application has already downloaded them?
I'm not 100% sure why this problem occurs, but it is related to Prism. The way we've solved it is add references to all the startup project and each of the sub projects even though they're not directly referenced but that project.
Make sure that the "Reduce XAP size by using application library caching" is enabled for all your projects.
Make sure that Parent1.csproj has references to all your 3rd party dlls.
Add these same references to child1.csproj and child2.csproj.
Double check you have extmap files for all your 3rd party dlls. If these are missing the dlls will be loaded into the XAP files.
Adding the references to the module projects and setting Copy Local to false on them will work, which is more or less what the accepted answer describes. However, Application Library Caching is not supported in Prism modules, so that may not work as expected.
If you have a lot of assembly references, adding them in this fashion is not very maintainable. You could also use a post-build step that removes unneeded assemblies from the XAP. Here's a short article that I wrote about how.
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 have inherited a Windows Forms application and I have found that a .EXE file gets generated into the obj\Debug folder everytime I compile.
I am more a Web Forms kind of developer so I am a little confused as to what is happening here. Why is it a .EXE and not a .DLL? What does this file actually represent? Is this the default behaviour for Windows Forms applications? Or, did my predecessor have to set it up up somehow?
As far as I can tell, the solution does not have a deployment project.
Their are many types of win application in delhpi. If u create windows form, .exe will be craeted in the debug folder similarly if you are creating Dynamic Link Liberary (DLL) .dll files will b created. These files are created each time when you compile the application.
Why this is a problem? Console application projects have exe file in the obj/Debug folder too. The obj folders are NOT used for running the application - they are used for creating the end binaries in the bin folders.
If the question is about exe vs dll then compiled exe file is used to run the application. In the web environment you used dll because ASP.NET new how to run code from it. But Windows knows how to run exe files, so any of your code actually can be compiled to an executable.
Every application be it web or windows would have an entry-point for execution. Anything in compiled form in .Net is an assembly which need not always be a DLL file. An EXE file is a .Net assembly with an entry point and few headers in the beginning of the file that identifies itself as a stand-alone executable to the windows operating system. In case of your web-application your asp.net pages are the entry points that users would type in a browser and start the application. In case of a stand-alone windows forms desktop application, it is an EXECUTABLE file, which user can click on run.
I am more a Web Forms kind of developer so I am a little confused as to what is happening here. Why is it a .EXE and not a .DLL?
Having said this, It is also important to note that, just like the asp.net is not the only platform to develop web-applications [you have php, jsp, etc.], .Net windows forms is also not the only way to create stand-alone executables. You can make EXEs in C, C++, VB, Delhpi, etc. only difference would be that they will not be .Net assemblies but all of them including .Net executables will have an entry-point to start execution from and the EXE header that identifies them as executables on the host windows operating system.
Why would it be a DLL? It's an application - it has to be launchable, unlike a website which lives "inside" a web server (effectively). The exe file is the application (along with any libraries it requires, of course). You double-click on it, it will launch the application. No problem.
Having said that, you should pretty much ignore the obj directory - it's just an intermediate directory. The bin directory is the one you should be taking build results from.
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