I'm using TortoiseSVN and Visual Studio 2008.
Is there any way to update my project's assemblyinfo.cs with svn's version in every build?
For example, 1.0.0.[svn's version] -> 1.0.0.12
You could use the SubWCRev tool which comes with TortoiseSVN (also available separately).
Either run it from a command line or use the COM-Object it offers.
The SubWCRev command line tool replaces keywords inside a file with information from your svn working copy. An example is shown in the docs.
I do this in my build script:
<SvnInfo LocalPath=".">
<Output TaskParameter="Revision" PropertyName="BuildRev" />
</SvnInfo>
<FileUpdate Files="protobuf-net\Properties\AssemblyInfo.cs"
Regex='(\[\s*assembly:\s*AssemblyVersion\(\s*"[^\.]+\.[^\.]+)\.([^\.]+)(\.)([^\.]+)("\)\s*\])'
ReplacementText='$1.$2.$(BuildRev)$5' />
using the community build tasks. This essentially applies a regex to the AssemblyInfo.cs, replacing the current revision with the svn revision.
You could use the $Rev$ svn keyword but that will give you the last revision of the file, I think you want to get the HEAD revision number.
Give a look to this question:
How do I sync the SVN revision number with my ASP.NET web site?
How do you feel about a Visual Studio addin doing it?
Yes, you can add a pre-build event that calls a script which
calls svn info to extract the current revision number (if you do an update before, you can directly include the keyword $Revision$ in a file, check also this post);
modifes your Properties\AssemblyInfo.cs file accordingly.
What I usually do is transform a AssemblyInfo.cs template when the project is built. The script is necessary to adapt the form of $Revision$ to the syntax of this file, unfortunately.
The interesting properties are (where the template strings are between '$'):
[assembly: AssemblyVersion("$v$.$build$.$Last Changed Rev$")]
[assembly: AssemblyFileVersion("$v$.$build$.$Last Changed Rev$")]
Edit: svn info is part of the standard SVN client, not TortoiseSVN as pointed out in another post. Easy to install though. However, TortoiseSVN comes with SubWCRev.exe which transforms a file with keyword substitution, so it would do the trick if you update your local copy.
In Visual Studio 2008, you can define a pre-build event that can launch a script or small program. Within this script or program, you can use the svnversion command to get the repository revision, then parse your AssemblyInfo.cs and modify the version number to what you desire.
I'm not sure if TortoiseSVN comes with svnversion, but it does come with the Windows SVN build provided by CollabNet
I created an SVN version plug-in for the Build Version Increment project (which is named in popester's answer). This SVN plug-in will pull the latest change revision number from your working copy and allow you to use that in your version number, which should accomplish exactly what you're trying to do.
Related
This question is a complement for the post How to change the output name of an executable built by Visual Studio.
After reading this post I did the following:
Firstly, I followed the answer for this post and I could define the executable file name successfully.
Now, I would like to know if instead of only define the name as "Demo.exe" as mentioned in the example post above, it would be possible to embed the version defined in AssemblyInformationalVersionAttribute or in AssemblyVersionAttribute in the built file, resulting in something like "Demo_v1.0.0.0.exe"?
I'm developing my application in C# WinForms, using Visual Studio Express 2017.
Why would you want to change the name of the executable? Whenever you try building a Setup for your application, you need to change the Setup to include the new file. And when you install an update, your Setup needs to know all versions of your executable in order to delete the old version. That's just not what you want to do.
If you want to keep all versions of the software for yourself, come up with a different solution, e.g. moving the executable into a folder which has the version number.
That said, I have done this for Setups, so customers can download different versions of the Setup. I did that using a commercial tool called Visual Build, but there are other build automation tools available. So, my answer is: set up a continuous integration / continuous delivery pipeline (CI/CD) and automate the step there, not in Visual Studio.
From the project properties, you can add Post build event command line to rename your exe
pseudo
Maybe you can create another console renamer.exe which reads version defined in AssemblyInformationalVersionAttribute or in AssemblyVersionAttribute of your app and renames it and then call that renamer.exe from Post build event command line
write a powershell script to rename the newly built exe and call that script from Post build event command line
Our team want to enforce styling rules in our C# project. I read somewhere some time that Microsoft said that ".editorconfig is the future" so we want to use this. NOTE: We don't want to use ReSharper.
C# has a lot of great rules that can be defined in editorconfig now, see Microsofts own editorconfig guide
We want to use this, and enforce that the rules set in the editor config is followed both when coding in Visual Studio and enforce that the code commited to git is following the rules.
When adding the .editorconfig rules, we get great linting on our files like this:
Running a fully enabled "Code Cleanup" in Visual Studio 2019 it completely formats our code as desired:
Question 1: How can we make the "Run Code Cleanup" run automatically on save/build? Even if we set certain rules as severity ":error" the compiler still don't complain about issues in C# files on build.
NOTE: I have tried the plugin for Visual Studio called Format document on Save but it does not follow all the rules set in the editorconfig (only a few, like fixing tabs/spaces and end of file newline)
We would also like to make sure that all commits to our git repository gets formated.
There is a tool called dotnet-format that is supposed to format the code according to the editorconfig rules.
We would like to add a pre-commit hook that runs the following 2 commands:
dotnet tool install -g dotnet-format
dotnet-format
This would work fine, but the issue is that dotnet-format also don't fix the issues in files with code giving severity ":error".
dotnet-format behaves the same way "Format document on Save" does, only fixing a few things like tabs/spaces and end of file newline.
EDIT: dotnet-format appearently only supports a few of the rules for now as per their Wiki
Question 2: How can we, from a command line, run a command behaving the same way as the "Code Cleanup" command in Visual Studio 2019 does?
I am able just to answer the your first question:
I have been looking for this and I found a extension called Code Cleanup on Save, you will just have to install it and configure it at Tool->Options->Code Clean up on Save, decide what of your profiles you want to set and that's all,
I hope it will help you!
I cloned an existing but almost empty project on my local machine through GitHub for Windows. Then I opened it in VS 2017 and added a few classes after what they all became marked up as "ignored" with red icons with "minus" sign on them.
When I tried to make a commit, (I want to make commits and push through GitHub App), non of the files where pushed.
Then I tried right-clicking on the files and adding them to source control. Then "minus" signs became "+".
I also thought maybe the problem lies in the fact that I didn't stage them. So I did (in VS). But I still cannot push these files. After an attempt to make a commit in GitHub app all my .cs files again become marked up with "minus" sign.
What is the reason of it and how to make them not be signed as "ignored"?
They are (most likely) being ignored by .gitignore file.
If you can't see anything obvious (check substrings of the file name as well as extension), then look for these and remove them:
/*
!/content/
Not sure if this helps the #Tanya, and here's my partially similar experience.
And sadly (as a reflection on my powers of observation) it turned out to be exactly as #goamn had suggested.
I was building a new console app (very short list of files) to help me do a backup activity, and I had called the VS project “backup”.
What I missed (at first and second glance) was that in the .gitignore was the line (in the “Backup & report files” of all likely places!):
# Backup & report files from converting an old project file
# to a newer Visual Studio version. Backup files are not needed,
# because we have git ;-)
Backup*
Merely removing this line from that file, even after I had (what appeared to me to be a horked) repository already set up and non functional in github, fixed it right up. I was able to commit the files with no problem.
Hope that helps.
Say the .gitignore file has this:
*.log
in it.
Now, a project that's named with a .Log suffix will not be committed(for example a project called CompanyName.Domain.Service.SubService.Log)
To add such a project to source control, you'd need to manually add it using:
git add <RootFolder>/<CompanyName.Domain.Service.SubService>.Log/* -f
This will force commit the change contrary to the opinion of the .gitignore file. However, this does not remove the .log from the .gitignore file. But once the force commit happens, the project is already in source control and will therefore not be subject to the .gitignore file. Thereafter, commits to this project will be committed.
You need to add first, ensure they're staged, commit, then push
I am working on documenting a winForms project that isn't completely done being written, meaning there is another programmer who write the code right now. So I've already wrote some importent comments in a copy of the project.
In addition I use sandcastle to bulid the help file.
My question: what is the best way (if there is one) to copy the comments from the old copy of the project to the new version of it?
Maybe sandcastle can do something like import a documentation to a project?
I know it wasn't so smart to do so, still I have to check if there is a way to save the documentation work.
Visual Studio has a built in file difference function you can use to see where the two files are different. It should be then a matter of copy and paste of the changes you have made over to the "gold" copy of the file your other programmer has changed.
This link shows how to Compare two files in Visual Studio 2012
"You can invoke devenv.exe /diff list1.txt list2.txt from the command prompt or, if a Visual Studio instance is already running, you can type Tools.DiffFiles in the Command window"
Hi I have a c# project in visual studio 2010 and Im wondering how to do the following
I have deployed this project already to a tester.
It uses a SQL database in the backend.
When I published a new version and sent him the new installer he had to remove the old version first which in turn removed his database.
What I'm looking for is a way to publish the project such that it overwrites the old stuff that has changed while leaving his database in tact.
(This would also need to but probably would circumvent the message that you can't install because its already installed in another location)
Thanks in advance for your help
The absolute simplest solution is to not use an MSI or an installer to update the program. Since this is a .NET app, it just needs to be copied to the file system. (XCOPY deployment)
The next simplest solution is to use a true database - have the database be something that is set up separate from your application.
This might also work, but I have no time to test it personally: If this is a .dbf file or another file included with the project, you might be able to change the option on that file by selecting "Copy if newer" on the Copy to Output Directory Property in the properties pane for that DB file.
Could you use ClickOnce? It is super simple.
Here is a good tutorial - http://www.youtube.com/watch?v=t4BTLdIMYEY