Auto-increase project version number in Visual Studio

In many situations, you will need to have an auto-increased version number in assembly for your project. For example, if you are developing or updating a NuGet package for one or multiple projects sharing.  Every time when you update the package you will need to change the version number so that the projects using this package will be able to update the package to the latest version. In stead of changing the assembly version number manually on each build, Visual Studio can do this for you automatically.

The solution is to go to Project Properties -> Application, click the button named “Assembly Information…


Then in the Assembly Information windows, change the 3rd box for version information to “*”, then click OK.

Now each time when you build the solution or project, it will generate a version number like 1.0.X.Y, where X is the number of days from year 2000/1/1 and Y is the number of seconds from midnight divided by 2.

If you the “*” at the 4th box in the above step, the version will be generated as 1.0.0.Y where Y is the number of seconds from midnight. This may cause versioning issue. For example,  when the last version was build in afternoon yesterday (e.g. Y=15000, version is and the new version is built today morning (Y=8000, the version number will be,  then the new version number is smaller than the old version.

Finally, you could also achieve the same by modifying the  AssemblyInfo.cs file directly if this is preferred. Just to change or add the below two lines in the file.

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]

If you encounter an error “a wildcard is not allowed in this field” for File Version. The solution is to empty all 4 boxes in the File Version row.  That way the File Version will be generated same as the Assembly version. If you edit the AssemblyInfo.cs file, you could delete the line for AssemblyFileVersion.

More about the version number:

More about setting up auto-version number:

More about the wildcard-not-allowed error:

Resolve the docker error “while creating mount source path … no such file or directory” in Windows

Recently when I try to run my docker containers using “docker-compose up” command, it suddenly shows an error:

ERROR: for wh_ser_website_1 Cannot start service ser_website: error while creating mount source path ‘/c/dev_projects/…./services/website/source ‘ : chown ‘/c/dev_projects/…//services/website/source’ no such file or directory

This is actually coming from my docker-compose.yml file:

    - ./services/website/source:/var/www/html

The first reaction I had was to check the folder path if there is any typo or accident deletion.  But every file/folder is just sitting there perfectly fine.

Secondly, I checked my share drive in docker settings, the C: drive has already been checked. No issue about it.

This error has never happened before, and those containers were running perfectly a few days ago.  Nothing has been changed except that I created symbolic links to better organize my projects, and that is the reason.

Here is the thing. The project folder is actually stored in X:\PersonalDir\Cloud\Projects\…..\services\website\source.  The path is just too long and I hate to go down many levels to find my files, so I reorganized my project folders by creating a virtual folder in C:\dev_projects using symbolic link to link to X:\PersonalDir\Cloud\Projects . This gives me the convenience to access all my project folders quicker without really moving my actual project folders and files in X:  as shown below.

When I run “docker-compose up” in the virtual folder C:\dev_projects\, the above error occurs. I suppose this is because docker is going to access the folder from C:\dev_projects but is actually stored in X: .

When I change to the project folder in X: drive and run the command again, the error is gone. Problem solved.

Base on this experience, I believe there is an issue in docker to work with Windows symbolic link at the current version.

Hope this helps anybody in such situation.

Build your application with any programming languages you like

Look! With these few easy steps, you could break your one giant projects into many micro-services and have them running in separate environments. Each service can be developed and maintained using its own languages. No more fights for “best language for the project”. Just use the language that you are most familiar with and most productive for the tasks in that specific service.