I have a solution with multiple projects and created a SharedAssemblyInfo (as links) so that I can share the version number across all the projects. I also have an AssemblyInfo file in each project for the assemblyName and guid. When I build and run locally it runs fine. When I attempt to build, MSBuild throws an exception when it tried to retrieve the version number. I'm getting a null reference exception when I tried to retrieve the assembly version. Any ideas?
So I figured out the error. In tfs, where I create a new build definition, you can specify a build template. We are using our own custom build template, which I don't have access to see what its doing but I'm able to use it. In the process section there was a line called "Increment version number". This was by default selected as true. When I set this to false I can get it to build now. I assume our custom build template must be specifying this action to use the assemblyinfo.cs file. So I could modify our build template to look for version number in sharedassemblyinfo.cs or in my case I just marked it not to increment version number.
Related
I'm working on a project where plugins are deployed in DLL's.
When deploying a DLL, it gets locked by the application. To update it I have to change the name of the DLL (since I can't overwrite the original), and update the app database to use the new version of the library.
I'd like to make this as automated as possible.
In AssemblyInfo, I've set the [assembly: AssemblyVersion("1.0.*")] to automatically increment.
I'm hoping that I can pull this version into the project properties Assembly Name, so that it automatically appends the version number to the generated DLL.
Is this possible at all with VS/C#?
Following Hans advice that the file renaming can't be done during the build, I've decided to rename the file after build.
In order to find the version number quickly for renaming, I've removed the AssemblyFileVersion line from the AssemblyInfo file. Which will set the file version to the version number. Automatically Update Assembly File Version
After building the DLL I can check the file properties, where the version number will be listed as File version under the details tab.
I'll copy the version number from here and append it to the DLL name.
When building an application using a traditional language, the build version number was embedded as the version in the compiled executable (right-click properties, and there the version would be). It was a magical and beautiful time as this process was automatic, and in sync with whatever the current publish build in your project was. (when i state build in reference to version number, what I actually mean is the entire version string Major.Minor.Build.Revision )
Now, Visual Studio still has the same feature, except there doesn't seem to be any way to naturally embed this into the published executable. It does a fine job at using it to name the folder where the build is located, but the exe inside ALWAYS reads v1.0.0.0, even after modifying the AssemblyInfo file with the following line :
<Assembly: AssemblyVersion("1.0.*")>
.. which only sets arbitrary numbers based on the current time for the masked parts, and even still, this isn't what shows as the file version..
When attempting to change the AssemblyFileVersion value, from
<Assembly: AssemblyFileVersion("1.0.0.0")>
to :
<Assembly: AssemblyFileVersion("1.0.*")>
It is unsupported. Even if it did work, this would NEVER match the build of the project :
How can I embed the above number in an automatic way into the compiled executable so that the version shows up here :
Notice how neither the file version or the product version reflect neither the AssemblyVersion or the version in build settings.
If you are using the 'Release' exe,then you should change the version in:
Project > Properties > Assembly Information
We have our AssemblyVersion and AssemblyFileVersion attributes in a separate properties file. This is because they are "linked" between all the projects and are updated by the build server. We don't want to have to manually update versions after every build or release.
AssemblyInfo.cs:
[assembly: AssemblyTitle("MyProductTitle")]
[assembly: AssemblyCulture("")]
[assembly: Guid("579eb194-08f1-44fc-9422-21aaf6cb2963")]
AssemblyVersionInfo.cs:
[assembly: AssemblyFileVersion("0.0.14056.19")]
[assembly: AssemblyVersion("0.0.0.0")]
The problem is that our build server complains with the following warning for each project:
CA1016 : Microsoft.Design : Add an AssemblyVersion attribute to 'MyProduct.dll'.
When building the projects locally, the actually DLL files in bin have all the version numbers applied (file property dialog):
When looking at the project properties in Visual Studio, the version info is not detected in Assembly Info:
My guess is that this is due to AssemblyVersion and AssemblyFileVersion not residing in AssemblyInfo.cs.
Is there any way to "include" the custom AssemblyVersionInfo.cs file?
More than one thing going wrong here:
The dialog is pretty empty because it strictly looks at the AssemblyInfo.cs file for attributes. And will write them to that file if you enter a version number. Using a separate file is not a great idea.
The Windows "Details" property sheet is agnostic of .NET, it only displays the content of the unmanaged version resource in the file. Which is only indirectly related to the attributes in your C# source code, the C# compiler auto-generates the unmanaged version resource from the attributes. Sadly, the super-important [AssemblyVersion] number is not displayed in this dialog, XP was the last Windows version that could still display it.
You probably got CA1016 because you left the version number at 0.
Windows not displaying the [AssemblyVersion] is not a good reason to skip the attribute. If it is important to you to see it in the property sheet then simply make the [AssemblyFileVersion] the same as the [AssemblyVersion]. Do keep in mind what it used for, if you change the [AssemblyVersion] then all of the projects that have a reference to the assembly need to be recompiled.
There's bad history between the Windows and DevDiv groups at Microsoft, I don't want to get into the details of it. Let's just say that Windows does very little to accommodate .NET. It is up to us to work around this.
I made a change to an ancillary DLL that my project uses, built it of course, renamed the legacy DLL to *.dll_old, and copy and pasted in the new version of the DLL to that same folder.
However, when I then ran the app that uses the DLL, it errored out with:
"An expected error has occurred...bla bla bla...or select Details for more information.
I did select Details, and saw:
TypeLoadException
File or assembly name <name of the DLL, which I just replaced>
Version=<bla>
Culture=neutral
PublicKeyToken=null, or one of its dependencies, was not found.
UPDATE
Based on the comments, I guess there's more to replacing a DLL than one might expect. I don't know if this is significant or not, I thought replacing a DLL would be like replacing an EXE, but maybe not: the DLL project's AssemblyInfo.cs says,
[assembly: AssemblyVersion("1.3.*")] // used by .NET framework only
[assembly: AssemblyFileVersion("1.3.0.308")] // File Version - increment here
[assembly: AssemblyInformationalVersion("6.3.0")] // Product version - set to current IEQ system
...and the Version in the err msg is "1.3.3889.27539"
Do I need to update one of these lines (I would guess the middle one, if so) to that value (1.3.3889.27539)? Or...???
UPDATE
So since the .DLL is not strongly named, I tried simply removing the reference (to the old .DLL) in the project that uses the DLL and then adding it back again (same file name, different version). I see, though, that updating the .DLL does not change the version numbers shown above - IOW, the AssemblyInfo.cs does not get updated when building. Should it? Do I need to manually update these vals?
It seems that types inside your original DLL were referenced by your EXE file. WHen you replaced it with your own version the references were messed. The EXE file contains metadata table with a list of types, methods, properties, etc that it references and exact version of the assemble expected. Providing something else even if everything was the same but the version number is simply not the same thing. That is why you are getting the exception.
UPDATE: Yes it is possible. However it involves creating a manifest file. For more information check this MSDN web site on Redirecting Assembly Versions. Also, keep in mind that only strongly signed assemblies can be redirected. Non-signed assemblies will be ignored.
When I try to run the project it says:
Error while trying to run project:could not load file or assembly 'Project.exe' or one of its dependencies.
The module was expected to contain an assembly manifest.
When I ran the exe from the debug folder I got this error:
application unable to start correctly (0xc000007b)
I also reinstalled Visual Studio but it doesn't seem to work!
The module was expected to contain an assembly manifest
It is a low-level assembly loading problem. The CLR has located a file with the right name but when it tries to load the assembly, it finds out that the file doesn't contain a proper manifest. A .NET assembly must contain a manifest, it contains metadata that describes the assembly, listing the types in the assembly, etc.
If you have no clue what EXE or DLL might be the troublemaker then you can use the Fuslogvw.exe utility:
Start it from the "Visual Studio Command Prompt".
Click the "Settings" button and click the "Log binding failures to disk" radio button.
Switch back to VS and start the program and wait for the exception to occur.
Back to Fuslogvw, click the "Refresh" button and double-click the added entry.
It shows you the file it found.
Several possibilities, a common one these days is to trying to load a .NET 4 assembly with an EXE that asked for CLR version 2. That requires an app.exe.config file that forces CLR 4 to be used.
In my case I just change Target Framework(.Net Framework 4) in Project Properties. It solves the problem.
I have the same problem when I use Vs2012 utimate to publish Asp.net Mvc4, then upload dll to server.
I fixed it by build code as Release mode then upload all dll in bin folder to server.
IN my case it get fixed by just going to project properties and set-->startup object projectname.program and build->platform target--> x86.
i just resolve this by problem by restarting System as well in project properties i set to multi users as well in combo box start option.hope this will help u.
0xc000007b is "STATUS_INVALID_IMAGE_FORMAT". From experience, this points me to the project properties.
A few things worth checking out:
Check to see if all the build options are set to either x86 or x64, depending on your system architecture, or AnyCPU.
If you're using dlls, consider whether they were compiled for your target architecture or not. If not, then recompile them accordingly or get them in the right version from wherever you got them.
Finally, check if your project assembly and loaded assemblies have different names. That seems to make things go boom as well.