Using Visual Studio 2019 to build a C# Class Library. The assembly has an AssemblyInfo.cs file with these attributes:
[assembly: AssemblyVersion("8.0.*")]
[assembly: AssemblyFileVersion("8.0.0.0")]
In .csproj, the Deterministic tag was set to false, the project was then reloaded and rebuilt. Right-click the assembly and Properties > Details shows:
File version = 8.0.0.0
Product version = 8.0.0.0
What am I doing wrong?
Ideally File version would have the format 8.0.BUILD.REVISION with BUILD the days since 2000-01-01 and REVISION half the seconds since 00:00. And Product version would be just 8.0.0.0. Is this possible?
Update
After some experimentation, commenting out AssemblyFileVersion:
[assembly: AssemblyVersion("8.0.*")]
//[assembly: AssemblyFileVersion("8.0.0.0")]
gives part of the answer. Now Properties > Details shows:
File version = 8.0.7710.25829
Product version = 8.0.7710.25829
Progress! But is there a way to have an auto-generated BUILD and REVISION for File version but to have a fixed Product version?
The answer from #MarkBenningfield did not work for me, but prompted me to experiment. Here's the solution that gave the result I needed. In AssemblyInfo.cs, set the lines to:
[assembly: AssemblyVersion("8.0.*")]
[assembly: AssemblyInformationalVersion("8.0.0.0")]
(and set Deterministic to "false" in the .csproj file).
Now the assembly builds with auto-generated BUILD and REVISION for File version, while displaying the Product version with my fixed string.
Visual Studio gives you the tags AssemblyVersion and AssemblyFileVersion by default for new projects. You need to swap AssemblyFileVersion for AssemblyInformationalVersion.
You've got it turned around. Use
[assembly: AssemblyVersion("8.0.0.0")]
[assembly: AssemblyFileVersion("8.0.*")] // older versions of VS use full asterisks ("8.0.*.*")
This will give you a fixed version for the assembly, and let you track build increments with the file version.
Related
I'm using VS2022, and I received an old project, where iTextSharp was used, but I can't determine a specific version of the mentioned.
I've tried - Tools -> Nuget Package Manager -> Manage Nuget Packages for Solution...
But was unable to find iTextSharp.
Thanks in advance.
It sounds like the assembly has been included directly in the source control, as was common place before nuget. Take a look in your project's references and you should be able to locate the dll. Checking the file's properties in VS should show you the assembly's details in the properties panel and should also show you which version is being used, if not the path or filename may give you a clue as to the version being used.
Where to define this command in csproj file?
bin\Debug\net47\MyApp.exe
I m using .net core 2.0.0 SDK. I m not getting RunCommand in Intellisense. Also while building my solution, I have 7 projects and main project is of type console application and its Output Type is EXE. Solution gets built successfully. While I press F5 it gives me MessageBox containing message like "Unable to run your project. The RunCommand is not defined."
How to solve this?
This is typically set by the SDK. Most likely you are targeting netstandard2.0 (was it a Class Library project that you later added a Main() to?). Try targeting the specific runtime+version - in your case netcoreapp2.0 or net47 - instead.
If you want to build both Core and Full Framework you can specify multiple target frameworks by separating them with a semicolon and changing the TargetFramework tag name to plural (TargetFrameworks):
<TargetFrameworks>net47;netcoreapp2.0</TargetFrameworks>
Alternatively, you should be able to specify a <RunCommand> inside <PropertyGroup> in your .csproj file. FWIW I can't seem to get anything to show up in Intellisense except the generic <PropertyName> and anything I've already added to the list.
An example would be:
<RunCommand>bin\$(Configuration)\$(TargetFramework)\$(AssemblyName).exe</RunCommand>
I'm porting a project from MSVS2005 to MSVS2010. I just loaded the solution in MSVS2010 and let the wizard convert the projects.
I ran into the property manager and found these property sheets (top-to-bottom):
Upgrade from VC 7.1
Microsoft.Cpp.x64(or Win32).user
Multi-byte Character Support (not editable)
Dynamic Link to MFC (not editable)
I understand the last three ones but I don't know what is the purpose of Upgrade from VC 7.1. Can someone give me a little explanation?
P.S. I found C/C++, Preprocessor, Preprocessor Definitions = _VC80_UPGRADE=0x0710;%(PreprocessorDefinitions) in property page "Upgrade from VC 7.1" but in project properties I see NDEBUG;WIN32;_LIB;%(PreprocessorDefinitions). What does all this mean? What is the _VC80_UPGRADE=0x0710 macro?
A project property sheet simply pre-sets settings for a project. Unless the project overrides the setting. Which your project does, it overrides the "Preprocessor Definitions" setting. The extra "%(PreprocessorDefinitions)" macro ensures that the definitions from the property sheets are appended and not lost.
So the definitions that the compiler sees are NDEBUG;WIN32;_LIB;_VC80_UPGRADE=0x0710
The _VC80_UPGRADE macro helps your old project to compile and run correctly on Visual Studio version 2005 or later. It is used, for one, in vc/atlmfc/include/afxres.h to ensure that the manifest resource has the correct ID.
You are skipping many VS and Windows versions so this doesn't exactly mean you'll have no problems at all. Particularly UAC can give you a headache.
Is there any way to use a custom format for assembly versions, when building them with MSBuild?
For example, we tried to use a version like "0.16.10r2.10717" But we got this error:
error emitting 'system.reflection.assemblyversionattribute' -- The version specified '0.16.10r2.10717' is invalid.
I searched around the web, but seems no one asked for a solution of this. Is it possible?
We use Microsoft Visual Studio 2010, and FinalBuilder 7 for building our project.
AssemblyVersion and AssemblyFileVersion both must be composed of up to four integers, period-separated, each of which is no larger than 65534 (UInt16.MaxValue-1). Any of the following are valid (C# syntax):
[assembly: AssemblyVersion("1.2.3.4")]
// Let the compiler generate the build and/or revision numbers
[assembly: AssemblyVersion("1.2.3.*")]
[assembly: AssemblyVersion("1.2.*")]
There is another attribute, AssemblyInformationalVersion, that accepts a string as the version; it can be used when you want to use more complicated strings (especially when including a commit ID from a DVCS).
// Use complex version number
[assembly: AssemblyInformationalVersion("0.16.10r2.10717")]
// Include Git commit ID
[assembly: AssemblyInformationalVersion("1.2b1-g39d1c0f")]
Briefly, the difference between these attributes is:
AssemblyVersion: This is used as the CLR version of the assembly. When the assembly has a strong-name, this is the version that is validated against.
AssemblyFileVersion: This is the Win32 file version resource, and is displayed in the assembly's properties in Windows Explorer.
AssemblyInformationalVersion: This is accessible at runtime via the Application.ProductVersion property. It is also used in the Application.UserAppDataDirectory path.
I've inherited a .NET application that automatically updates it's version number with each release. The problem, as I see it, is the length and number of digits in the version number.
An example of the current version number format is 3.5.3167.26981 which is a mouthful for the users to say when they are reporting bugs.
What I would like is something more like this: 3.5 (build 3198). I would prefer to manually update the major and minor versions, but have the build number update automatically.
Even better, I don't want the build number to increment unless I am compiling in RELEASE mode.
Anyone know if there is a way to do this -- and how?
In one of the project files, probably AssemblyInfo.cs, the assembly version attribute is set to [assembly: AssemblyVersion("3.5.*")] or something similar. The * basically means it lets Visual Studio automatically set the build and revision number.
You can change this to a hard coded value in the format <major version>.<minor version>.<build number>.<revision>
You are allowed to use any or all of the precision. For instance 3.5 or 3.5.3167 or 3.5.3167.10000.
You can also use compiler conditions to change the versioning based on whether you're doing a debug build or release build.
At a previous company we did something like this by writing an Ant task to get the current Subversion changeset string, which we used as the build number, appended after the major, minor, and tertiary numbers. You could do something like this with Visual Studio as well.
Use a '*' wildcard in the AssemblyVersion attribute. Documentation is here. Note that if the application is built from multiple assemblies, the version you care most about is the one for the .exe.