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.
Related
In our project we're creating different NuGet packages (using suffixes) for different branches. In the .csproj file I'm trying to specify the specific version of a package that should be used.
Package names can be 1.2.3, 1.2.3-rc001, or 1.2.3-pr001.
First issue:
I tested using
<PackageReference Include="Package.Name" Version="[1.2.3,1.2.6)" /> where there was no 1.2.3. My understanding is it should use the next available version, but now it simply says the selected package is 1.2.3, with "Not available in this source". Updating NuGets also ignores this and simply updates to the latest release, 1.2.10. After that it overwrites the Version in .csproj, so the specified bounds are lost.
Second issue, that falls in with the first, is to specify to only use -pr* or -rc* versions. 1.2.*-pr* is not a valid option, so maybe our numbering scheme needs changing.
First issue: I tested using where there was no 1.2.3. My understanding
is it should use the next available version, but now it simply says
the selected package is 1.2.3, with "Not available in this source".
Actually, when you set different versions of a nuget package by floating versions(in your situation, 1.2.3<=version<1.2.6), NuGet chooses the package that's closest to the application and ignore the others. So it will choose 1.2.3 regardless of whether it exists in your current nuget caches.See this document.
So PackageReference will not reference the package based on the closest available version in your current cache and choose the newest version not matter whether it exits under your local machine.
Second issue, that falls in with the first, is to specify to only use
-pr* or -rc* versions. 1.2.-pr is not a valid option, so maybe our numbering scheme needs changing.
At the moment, prerelease versions cannot be used together with floating versions.It means that you cannot use any pre-release characters with floating versions . So -pr* and -rc* are illegal including 1.2.*-pr*.
During use, no characters about the pre-release version can appear.
Instead, you can use
1.2.*-*
Besides, the 1.2.*-beta1 is also illegal. Though it shows a version under Dependencies UI, you can not find it under Nuget Package Manager-->Installed which means that the package is missing and the project has lost it.
In addition, there is a similar issue which you can refer to.
When I open a generated solution+project file, I get the following warning for each platform I have in the project file:
path/to/project.vcxproj : warning : Platform '[some_platform, 0]' referenced in the project file 'project' cannot be found.
some_platform is a valid platform in the project, and building, browsing etc all work normally. There is no line number showing where the problem is.
My question is, what does '[some_platform, 0]' really mean?
Coming from Linux, I initially thought the quotes signify that I have [some_platform, 0] literally specified somewhere, which I don't. I don't see ,\s*0 used anywhere in the project file either. How do I decipher that message to be able to find out what it's complaining about?
This is a C++ project if that matters.
Edit: The only places , is even used are inside two messages and an SDK reference. So the [some_platform, 0] is definitely something constructed for the sake of warning, but what does the second part (0) mean?
Resolved: Why VS generates an output like that, I don't know, and who knows what the 0 means. However, it turned out that the platform name is something an SDK would register with VS (or something along those lines) and VS expects it case-sensitive. I had changed ORBIS and Durango to orbis and durango, causing the warning. Fixing the case makes the warning go away (the project was loading and building fine regardless).
I think you might have unmatched solution/project platform and build configurations, resulting in the rare case when visual studio defines or creates new ones: https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx ending in the odd platform names '[some_platform, 0]', '[durango, 0]' and '[orbis, 0]' you have.
Now this is entirely my guess (since I could not find any documents to confirm it). But what that 0 actually means, is the reference to the default build configuration that project should use when you target those individual platforms. For instance, you usually have lines similar to this in the solution (.sln) file:{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
In the case above you would use build configuration 0 as the default build configuration when using msbuild solutionname.sln from the console. But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate. There is more details and examples of the default build-configuration in this post: Visual Studio solution file - what does the "Build.0" mean?
Now back to what might actually be your real problem. You mentioned SDK references, have you made sure they are pointing to the correct place and any environment variables is properly configured in visual studio? If not, the problem might be related to the warnings mentioned here:
Platform 'Android' referenced in the project file 'san-angeles' cannot be found. The warning message on that question sure looks similar to the warning you have, only you have those oddly generated platform names.
Hope this will help you solve the problem.
In the WinPhone project of a VS 2015 v2 cross platform solution with Xamarin.Forms v2.2.0.13, two versions of ExceptionStringTable.resx are generated in the 'System Xaml/en-US' and the 'WindowsBase/en-US' folders with different contents. At the moment a dependent assembly, XCRRequiresAttribNotFound, found in both files, has conflicting values during build, one having an extra 'a' in the string. Since they are Build generated, why are they not the same value?
Comparison of Values
It looks like you have Platform specific assemblies referenced in your PCL. In this case, it seems that you have a reference to WindowsBase.dll somehow within your PCL. (This could be inside something like PresentationCore.dll or similar).
I would recommend that you do the following:
Compare this against a File -> New Forms Project (PCL) - To see what default references are within Forms by default in the PCL.
Replace any old desktop/platform specific code with the Forms APIs instead - https://developer.xamarin.com/api/root/Xamarin.Forms/
Profit!
If you have any further problems, I would recommend using grep on certain strings like WindowsBase to see exactly where this is coming from. In this case it's a reference to PresentationCore.dll
I'm running VS2010 Version 10.0.30319.1 RMTRel
I've noticed problems compiling VB.NET application. When I "rebuild" the solution it reports the build was successful. When I then click the run icon to begin debugging, then the compiler will report build errors(often related to referenced projects). I've confirmed all the projects are targeting the same framework and after an undeterministic number of times repeating the same steps, it will eventually compile. This seems consistent enough to me with other code bases to believe that it's a problem with VS. Anyone have any thoughts that might help improve my experience?
You should also check your configuration manager - probably some of projects are disabled for building in current build plan.
is this a rather large solution? If so, the order of build may be out of whack and the way to solve that is to set the build order of the projects to make sure all of the dependent projects are built first.
One common reason is circular references. You cannot do this in a pair of projects, but it can be done if you cobble together a long string of projects. The way to catch this is a dependency mapping tool with a visual representation of dependencies. You will see the items that refer back up to the top.
We upgraded our .net 3.5 projects (c#) to .net 4.0. When you look at the project file there are two tags that I'm trying to make sense out of:
<RequiredTargetFramework>3.5</RequiredTargetFramework>
<TargetFrameworkVersion>4.0</TargetFrameworkVersion>
Why are there two seemingly similar tags with different values?
The <RequiredTargetFramework> element was already present in your 3.5 project. It's associated with the assembly <Reference> and only present on assemblies that are not available in .NET 2.0
I don't buy much stock in the single mention of it in MSDN, I don't see how batch building has anything to do assembly references. Nor is it used in any of the 3.5 MSBuild .target files. I think the IDE simply uses it to put the warning icon next to the reference in the References node when you change the Target Framework to a version less than what's needed to support the assembly.
There are other elements like this in a project file that don't affect MSBuild but have an effect in the IDE. Like <SubType> and <DependentUpon> in the <Compile> element.
Have you found this one link? link text. TargetFrameworkversion is easy, that's the one you can change in the project properties to say which framework to build against. The article says that RequiredTargetFramework is used to batch items (but it's still not clear on it' real purpose other than it's not used a lot)
batches the Reference items by their RequiredTargetFramework metadata. The output of the target looks like this:
Reference: 3.5;3.5
Reference: 4.0
Target batching is seldom used in real builds. Task batching is more common. For more information, see MSBuild Batching.