I'm trying to raise the revision number with each build.
I've therefore tried to the project assembly information -> Assembly Version and File Version to
1 0 0 *
1 0 0 *
However, VS2017 tells me
"Assembly file version: In this field, wildcards ("*") aren't allowed.
How can I do this?
You should remove the AssemblyFileVersion attribute and just keep the AssemblyVersion. If AssemblyFileVersion is not present in the Assembly Information, the file version will automatically be set to the same as the AssemblyVersion at compile time.
Quoting the documentation:
If the AssemblyFileVersionAttribute is not supplied, the AssemblyVersionAttribute is used for the Win32 file versionthat is displayed on the Version tab of the Windows file properties dialog.
I found this:
https://marketplace.visualstudio.com/items?itemName=PrecisionInfinity.AutomaticVersions
It's hilarious that VS doesn't have this built-in.
I know this is a very old question, however it appears when googling "auto increment version visual studio".
Since the current answer doesn't really answer the question, this is what I did:
Assembly Version looks like 1 1 1 *
File Version like 1 1 1 0.
You cannot use wildcards (*) on the file version. If you use them on Assembly leave empty spaces after the wildcard (1 1 * EMPTY).
That works and the error
"Assembly file version: In this field, wildcards ("*") aren't
allowed."
does not appear.
If that still gives you trouble, you could remove the "deterministic" flag editing the .csproj
Yet another option is: https://neele.name/item/versioning-controlled-build
This one works with Visual Studio 2017.
I found it to be easy to use and has the advantage that you can choose to invoke it or not depending on if you are creating a test build or a release build.
Ensure the Projects "Deterministic" property is set to false by editing the .vbproj file:
<PropertyGroup>
<Deterministic>false</Deterministic>
</PropertyGroup>
Then open the AssemblyInfo.vb file and set the assembly version property like this: <Assembly: AssemblyVersion("1.0.*")>
Remove or comment-out the <Assembly: AssemblyFileVersion(...)> attribute since that cannot use wildcards, and if it isn't present, the file will inherit the version assembly number.
Setting the version number to 1.0.*, as in the above example, results in a version number similar to 1.0.8888.99999 where the build is equal to the number of days since January 1, 2000 local time, and the revision is equal to the number of seconds since midnight local time (without taking into account time zone adjustments for daylight saving time), divided by 2.
See the Docs site for details.
Related
Background
I am trying to axe away some elements that are no longer needed in clearcase. I think I might have subverted some policy, becuase after I ran a rmbranch on the files I wanted to remove, each file ended up in this state:
/some/directory/##/main/dev/retired_branch_time_stamp/oldViewNum1234/1/file.txt##/main/dev/new_view_3425_nickname/1
I am familiar with /some/directory/element##/some/branch but not with the double "##" notation above. Hench my question...
Question
What does the something##something##something notation mean in clearcase?
As I mentioned in "Access labels of file through extended filename as directory", everything after the ## is a version-extended pathname (see pathnames_ccase )
Branch: element-pname##branch-pname
Version: element-pname##version-selector
So:
The first part /some/directory/##/ is a VOB-extended namespace directory
Then you have the pname followed by a version selector.
That does refer to the concept of "extended namespace":
An extension of the standard Windows or Linux or UNIX file system that allows access to versions of elements.
I'm trying to edit the CPack settings so that the outputted package file has the correct version number in it. But that's not all. I'd like CMake/CPack to have all the places where the version number is updated also be set. The .so file should also be set. And whatever else needs it.
From where I sit, the CPack documentation appears to be telling us to repeat ourselves.
If I do nothing, the output file is like so:
mystuff-0.1.1-Linux.tar.gz
Let's say the version number should be 1.2.3.
I would think that this is the minimalistic CPACK settings to cause all the version numbers to be changed -- and I placed these lines in my CMakeLists.txt file:
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "My app is great")
SET(CPACK_PACKAGE_VENDOR "My Name")
SET(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_CURRENT_SOURCE_DIR}/README.md")
SET(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/LICENSE")
SET(CPACK_PACKAGE_VERSION_MAJOR "1")
SET(CPACK_PACKAGE_VERSION_MINOR "3")
SET(CPACK_PACKAGE_VERSION_PATCH "2")
When I build, the output file is still mystuff-0.1.1-Linux.tar.gz
If I repeat myself and do this:
SET(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
Now that variable is set, but the file is still mystuff-0.1.1-Linux.tar.gz
It seems that I must also change CPACK_PACKAGE_FILE_NAME
What other places do I have to re-state the version number?
This doesn't feel idiomatic. I must be missing something to make this automatic. Am I supposed to specify the variable at an earlier point in time? I also see some projects on the internet containing a CPackConfig.cmake file -- the file contains overrides, but I still see some repeating oneself going on in those as well.
This bug also mentions the same thing. Apparently, they do want us to repeat ourselves. (as of 2015) However, even if that is the case, I was wondering if anyone has found a work-around?
If no work around, how about a way to re-state all the variables so that they end up automatically set correctly? For instance, doing the following is a way to compose the version number by using the variables
SET(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
According to the documentation, the file name is composed like this:
SET(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}")
There are probably other variables that need re-setting. If I have to restate everything, then exactly what do I need to restate to be complete?
Make sure that you have the following line after setting the CPACK_... variables:
include (CPack)
This is the spot where CPACK_PACKAGE_FILE_NAME and others are automatically set, so the version variables (such as CPACK_PACKAGE_VERSION_MAJOR) must be already set at this point.
If you set your project's version via https://cmake.org/cmake/help/v3.0/command/project.html, you can set the cpack version like
set(CPACK_PACKAGE_VERSION_MAJOR ${PROJECT_VERSION_MAJOR})
set(CPACK_PACKAGE_VERSION_MINOR ${PROJECT_VERSION_MINOR})
set(CPACK_PACKAGE_VERSION_PATCH ${PROJECT_VERSION_PATCH})
include(CPack)
You'll probably want to look at the documentation for the PROJECT() command, which has a VERSION field. I'm not sure if it is wired through to CPack, but at least that is the idiomatic place for setting the project version.
https://cmake.org/cmake/help/v3.0/command/project.html
I am trying to use OpenCover With XUnit and MSBuild for our project and it works fine with one or two assemblies. But when the number of assemblies goes more than 2 it throws the below error:
EXEC : error : unknown command line option: MyProj.UnitTest.dll
[C:\CMR\Source\trunk\Build\Script\CMR.msbuild]
Committing...
No results, this could be for a number of reasons. The most common reasons are:
1) missing PDBs for the assemblies that match the filter please review the output
file and refer to the Usage guide (Usage.rtf) about filters.
2) the profiler may not be registered correctly,
please refer to the Usage guide and the -register switch.
Thought the problem would be with the 3rd assembly i added, so ran it individually again it worked fine. Below is the script I used:
<Exec Command='$(OpenCoverPath)\OpenCover.Console.exe "-target: $(XUnitPath)\xunit.console.exe" "-targetargs:C:\MyPath\UnitTest1.dll C:\MyPath\UnitTest2.dll C:\MyPath\UnitTest3.dll /noshadow" "-output:c:\OpenCoverReport\coverage.xml"'/>
And this is my assumption, for the purpose of posting here i had put paths of dll as C:\MyPath\UnitTest.dll but indeed the path is so huge and there are multiple assemblies with huge path. Does it has anything to do with this error?
try the -targetdir option of OpenCover
e.g.
<Exec Command='$(OpenCoverPath)\OpenCover.Console.exe -targetdir:"C:\MyPath" "-target: $(XUnitPath)\xunit.console.exe" "-targetargs:UnitTest1.dll UnitTest2.dll UnitTest3.dll /noshadow" "-output:c:\OpenCoverReport\coverage.xml" '/>
I have a project with 4 different sub projects. To specify the versions, I use the
SET(parent_VERSION_MAJOR 1)
SET(parent_VERSION_MINOR 0)
set(parent_VERSION_PATCH 0)
set(parent_VERSION 1.0.0)
and then I can use this in the sub projects if the add_subdirectory is used.
Q1. I could not set parent_VERSION based on MAJOR, MINOR and PATCH. According to the documentation is should be set automatically but whenever I try printing it, it is empty without using the last line in the code.
Q2. In case I want to build from sub directory only, I get an error shouting :
CMake Error at CMakeLists.txt:28 (set_target_properties):
set_target_properties called with incorrect number of arguments.
which is because I am using parent_VERSION there.
So I understand that it isn't able to get the parent_VERSION without running cmake from the top directory but how do I change the code such that it can build even without running from the top level.
I read about SET with INHERITED but I don't think that is what I need.
Here is how I solved it. If someone could tell me a better/more elegant way I'd be happy.
if(NOT parent_VERSION)
SET(parent_VERSION_MAJOR 1)
SET(parent_VERSION_MINOR 0)
SET(parent_VERSION_PATCH 0)
SET(parent_VERSION 1.0.0)
endif(NOT parent_VERSION)
The Story So Far
I've got a nice solution with a desktop application project, a few library projects, and a couple of development tools projects (also desktop applications). At the moment, my build server outputs all of the code into one OutputPath. So we end up with
drop-x.y.z\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
Helper.exe <-- developer tools
Grapher.exe
Parser.exe
... <-- the rest of the output
But, we're growing up and people outside of our team want access to our tools. So I want to organize the output. I decided that what we would want is a different OutputPath per executable project
drop-x.y.z\
Company.MainApplication\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
... <-- application specific output
Helper\
Helper.exe <-- developer tools
... <-- tool specific output
Grapher\
Grapher.exe
...
Parser\
Parser.exe
...
What I Did
I found this simple command. I like it because it retains all the Solution working-dir context that makes msbuild a pain.
msbuild /target:<ProjectName>
For example, from my solution root as a working directory, I would call
PS> msbuild /target:Helper /property:OutputPath="$pwd\out\Helper"
I'm testing this from PowerShell, so that $pwd resolves to the full path to my working directory, or the Solution root in this case. I get the output I desire.
However, when I run this command
PS> msbuild /target:Company.MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
I get the following error output (there's no more information, I ran with /verbosity:diagnostic)
The target "Company.MainApplication" does not exist in the project.
What I Need
The command fails on any project with a dot or dots in the name. I tried with many combinations of working directories and properties. I tried several ways of escaping the property values. I also tried running the command from a <Task> in a targets file.
I need to know either
A) How to fix this command to work property
B) How to achieve the same output with minimal friction
Try using an underscore as an escape character for the dot in the target parameter, e.g.
msbuild /target:Company_MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
Specify the target after the -target: switch in the format :. If the project name contains any of the characters %, $, #, ;, ., (, ), or ', replace them with an _ in the specified target name.
https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-build-specific-targets-in-solutions-by-using-msbuild-exe?view=vs-2019
Dan Nolan's answer and comments are correct. Just want to supplement the Microsoft documentation.
The /targets: switch is to identify a <Target to run in the project file. You need to supply your .csproj file as a an argument that is not prefixed by a /xx option marker.
You might also want to work based on the .sln file. In that case, you still dont specify the project in the .sln to build in this manner. I'll leave you to search up the correct syntax in case that's what you end up doing.