C# projects use a .resx file for resources. This is fine for strings, but it does not seem to have the equivilant of the old VERSIONINFO resource that the C++ project .rc files supported.
I can not believe that Microsoft has given up the idea of keeping track of executable versions ... so is there some VERSIONINFO-equivilent resource used with the .resx resource file? How do you bind version information into a C# project?
If you select a project in the Visual Studio Solution Explorer, right-click Project/Properties, and click the Assembly Information button, you can put your version information in the dialog box that opens.
The version information is stored in the resulting assembly's manifest.
Related
I'm trying this again, since yesterday my question drew no attention, and I'm guessing it was due to the lack of a well worded explanation.
When I build my WPF application, with the "Embed manifest with default settings" option checked, my AssemblyInfo.cs version info is embedded inside the output .EXE, and right-clicking the .EXE and checking properties shows that. I'm wondering how and at what point, does the compiler embed that data into my .EXE?
I ask because I recently had to create my own .res file to embed multiple icons into my .EXE with appropriate indexes. The problem with that is you need to select the "Resource File" instead of "Embed manifest with default settings option;" so you lose your AssemblyInfo version information and have to update and rebuild your .res file every time you do a release.
In short, I'm trying to find a way to compile my own .res file that uses my AssemblyInfo.cs version information and is automatically embedded for every build (my versions contain * definitions), so I don't have to worry about remembering to update my .rc and compile for the .res.
I have a installer app with a embedded .resx file with some information, like server name, port, password etc...
I have to generate this installer (this process is automated, and is done through our website) for each customer. This is working fine
I use ildasm for disassembler and replace the resx file, and then I use ilasm to make .exe again.
But after this process the .exe lost our icon, putting the default one in it's place.
I cannot find a way to change the default icon.
Thanks
You are missing out on a fairly obscure detail in a C# program. The executable the compiler generates also contains unmanaged resources. Required because Windows doesn't know anything about managed resources. This is something you can see with Visual Studio. Use File + Open + File and select a .exe generated by the C# compiler. RTM edition required, it doesn't work for Express.
You'll see at least 3 nodes for your program:
RT_MANIFEST contains the manifest for the executable. Very important on later Windows versions, it declares the program compatible with UAC. It prevents Windows from treating your program like an earlier Windows program that needs to be lied to when it does UAC verboten things like trying to write files to protected directories and trying to create registry keys in HKLM. The content of the manifest is a default one in most programs, you can get a custom one with the "Application Manifest File" project item template.
"Version" contains the version resource for the executable. It contains the info you see when you look at the properties of the executable with Windows Explorer. Its content is auto-generated from the [assembly:] attributes in your AssemblyInfo.cs source code file.
"Icon" contains the icon resource for your program. The one you don't have anymore.
You'll need to use the /resource option for ilasm.exe to embed those unmanaged resources into the patched executable. That requires a .res file, the compiled version of the unmanaged resources, produced by the rc.exe Windows SDK tool. Note how this is also exposed in the Project + Properties, Application tab, Resource file radio button.
You cannot ignore this requirement, you can live without the Icon resource but not the manifest, especially not in an installer program. Getting the .res file out of the original executable is going to be difficult, fairly sure that ildasm.exe doesn't support decompiling it. If a tool like Resource Hacker doesn't do it then you'll need to create a .res file for your program. Or review the wisdom of using ildasm.exe to do what you wanted to do.
I have created a application with localization using visual studio 2008 and .net compact framework 3.5 on windows mobile 6.1.
To achieve localization, I have used many resource file for this, one for each langauge :
StringResources.de-DE.resx
StringResources.es-ES.resx
StringResources.en-GB.resx
StringResources.fr-FR.resx
StringResources.nl-NL.resx
I also have a StringResources.resx file with default strings for fallback in case other culture not supported by my app is chosen.
I have also created a .cab file by using a "SmartDeviceCabProject" (vdproj type) to perform installation of this application on the device. (using msdn.microsoft.com/en-us/library/aa446504.aspx)
Here is the problem that I am facing:
When I change the culture to anything other than the nl-NL, I always get default strings.
Please also note that when I copy paste the "bin" folder of the application into the device, all culture strings are seen. Only when application is installed via the cab file that the problem occurs.
Also if i remove the StringResources.nl-NL.resx file and only have
StringResources.de-DE.resx
StringResources.es-ES.resx
StringResources.en-GB.resx
StringResources.fr-FR.resx
as the culture specific resources and recreate the cab file, now see that when I change the culture to anything other than the fr-FR, I always get default strings. So only the last culture file is effective always.
Just to be sure I diffed the dlls that were installed in each of the culture folders via the cab file on the device :
de-DE\Application.StringResources.dll
es-ES\Application.StringResources.dll
en-GB\Application.StringResources.dll
fr-FR\Application.StringResources.dll
nl-NL\Application.StringResources.dll
Strangely I found all the dlls are exact same. However if I diff the dlls present in the "bin" folder, they are found to be different.
Thus I believe that the .cab file build is causing the same DLL to be copied to each folder.
With the above explanation in mind, please help me with :
**1. What do I do to make the cab file install the proper DLLs to the folders?
Is there any other way to place the correct dlls?
IS there any other way to achieve localization?**
This problem is registered as a bug in WizCab.exe: Smart Device CAB Project includes wrong localized resources.
I have found that the best way around the problem is to:
Add post-build events to the projects with localized resources that copies the resources files to unique (file) names:
copy "$(TargetDir)sv\$(TargetName).resources.dll" "$(TargetDir)sv\sv_$(TargetName).resources.dll"
for each present language.
perform a build and overwrite these unique resource files with an empty file - otherwise the visual studio GUI will not allow you to rename (step 4) the added files.
Add the copied localized assemblies as files (right click on .cab-project and choose "View" -> "File System") under "Application Folder" to the correct localization folders instead of using references to project output.
Rename the added assemblies in the "File System view" back to their original names ("YourProject.resources.dll".)
Not very nice but it works.
I have a Silverlight 4 app that I'm building with Visual Studio 2010. I'm using Mercurial/TortoiseHG to do version control. Which files do I need to check in? By default, it checks in all sorts of .dlls in /bin/debug and stuff. Do I really need those? Or can I just grab code and content files? Do I need to version something to keep track of project properties and references, or is that contained within the .csproj file itself?
You don't need to include stuff in /bin or /obj. This is true of all VS solutions in source control. These are recreated upon every rebuild. Also, for Silverlight specifically, you don't need to check in the XAP file that is generated in the ClientBin of your web app.
From MSDN (via this social.msdn thread):
You can add the following files to Visual Studio source control:
Solution files (*.sln).
Project files, for example, *.csproj, *.vbproj files.
Application configuration files, based on XML, used to control run-time behavior of a Visual Studio project.
Files that you cannot add to source control include the following:
Solution user option files (*.suo).
Project user option files, for example, *.csproj.user, *.vbproj.user files.
Web information files, for example, *.csproj.webinfo, *.vbproj.webinfo, that control the virtual root location of a Web project.
Build output files, for example, *.dll and *.exe files.
It doesn't say anything specific about Silverlight projects though.
Is Mercurial/TortoiseHG integrated into Visual Studio? i.e. can you check out/submit from within VS?
If so, if you right click on the project name and select "Add Solution to Source Control" it should add those parts of the project that it needs ignoring everything else.
We're using our .NET Assembly DLL within native C++ through COM (CCW).
Whenever I make new version of my DLL, I have to send two files (.dll and corresponding .tlb) to crew that's using it in their code.
Is it possible to embed .tlb file as a resource in .NET DLL file?
It is not exactly straightforward to do this with Visual Studio .NET, but it can be done. At a basic level, what you have to do is this:
Generate your TLB file, e.g., "YourLibrary.tlb".
Create a Win32 resource script file called, for example, "YourLibrary.rc" using a text editor (such as Notepad, or File/New/File.../Text File in Visual Studio).
In the script file, type the following text verbatim (but substitute your actual TLB file name of course):
1 typelib "YourLibrary.tlb"
Save the script file to the same folder as the TLB file.
From a Visual Studio Command Prompt, change to the folder with the script file and compile it using the following command:
rc YourLibrary.rc
This will generate a Win32 resource file in the same folder called "YourLibrary.res".
In Visual Studio, right click the project node (e.g., "YourLibrary") in the Solution Explorer and select Properties.
On the Application tab, under "Resources", select the "Resource File" option and browse to the "YourLibrary.res" file from step 5.
Save and rebuild the project.
The TLB will now be embedded as a resource in the DLL such that other COM applications can read it.
If you regenerate the TLB file later you will need to repeat step 5 to recompile the resource file, and step 8 to embed the new version in the DLL.
All that said, you may be able to automate some of this with Build Events or by putting custom MSBuild targets into your project file, but that is a whole other discussion.