Scenario
I am in a situation at the moment where one of the projects I am working on depends upon a 3rd party API, which exposes a swagger descriptor in JSON which we consume using auto rest to generate the C# files for use in the system.
The c# files are generated as part of the build script however there have been instances where the API is updated, and although we do not use any of the new changes it does change some of the c# code which is generated which in turn may depend upon new files which are output from the build script but VS does not know they exist so does not include them.
Issue
So I am trying to find a way to tell visual studio from a build script or some sane way (Without manually changing a *.csproj file) to automatically include everything within a folder in its project, so is there a way to do this?
Other Info
I have deliberately not mentioned build script technologies as it is not really important, so I don't mind if I have to use msbuild tasks or other command line stuff as long as it works I can probably find a way to hook it in.
Also I know some people will think "why do you need to keep re-generating the files?", and we don't really, and currently we try to keep to a specific version, however ignoring that the question still stands, i.e how do you update files VS knows about from outside VS.
You can use wild cards in .csproj file. You only need to do this once
since you didn't give the folder name, I am suggesting a generic solution for you.
To prevent the Visual studio from expanding the wild card once you modify the porject list in Visual studio, you have to add it as property.
In PropertyGroup , add a property with like this
<PropertyGroup>
<IncludeFolder>yourFolder\**</IncludeFolder>
</PropertyGroup>
Then in add the following line to ItemGroup
<ItemGroup>
<Content Include="$(IncludeFolder)" />
</ItemGroup>
This will add everything in that folder to your project.
Also this wild card will not be expanded by the visual studio once you modify them from Visual studio solution explorer. (A weird process from Visual Studio)
Currently I have an instance of SonarQube 5.1.2 with C# plugin and MSBuild runner in order to analyze a 1.200.000 LOC project. I intend to reduce the classes that are analyzed, I created a sonar.properties file with the line
sonar.exclusions=**/Databases/**/*.*
but after reading the log from the analysis, files inside the Databases folder were analyzed. following the instructions from Eric Starr, I set this simple exclusion rule in the call of the runner:
"C:\sonarqube-5.1.2\bin\MSBuild.SonarQube.Runner.exe" begin /k:MyProject /n:MyProject /v:2 /d:sonar.exclusions="file:C:\codesource\Databases/**/*.*" /d:sonar.scm.provider=tfvc /d:sonar.tfvc.username=************* /d:sonar.tfvc.password.secured={aes}*************************** "/d:sonar.cs.vscoveragexml.reportsPaths=C:\codesource\CodeCoverage\Results.coveragexml"
I found that the runner creates a sonar-project.properties file, and it contains a lot of files located in the databases folder:
BC78C8C4-8ECD-47CB-9781-F621AE109FE4.sonar.projectName=myDatabase
BC78C8C4-8ECD-47CB-9781-F621AE109FE4.sonar.projectBaseDir=BC78C8C4-8ECD-47CB-9781-F621AE109FE4.sonar.projectName=myDatabase
BC78C8C4-8ECD-47CB-9781-F621AE109FE4.sonar.projectBaseDir=C:\\codesource\\Databases\\myDatabase
BC78C8C4-8ECD-47CB-9781-F621AE109FE4.sonar.sources=\
C:\\codesource\\Databases\\myDatabase\\Scripts\\PreDeployment\\PATCH_20150527_01.sql,\
C:\\codesource\\Databases\\myDatabase\\Scripts\\PreDeployment\\ROCOMMON.DBVERSION.sql,\
,\.....
as I understood, there should be no files in the databases folder. Am I wrong?
You are using the SonarQube Scanner for MSBuild which is very different from the regular SonarQube Scanner used for all other languages.
The sonar.exclude line that you are trying to use would only work if you would use the regular SonarQube scanner, because that takes in the Sonar-project.properties file. The SonarQube Scanner for MSBuild only has a SonarQube.Analysis.Xml file that contains project-related settings that you can tweak.
You can use couple of overwriting strategies for the SonarQube.Analysis.Xml file:
A project-specific property defined in the MSBuild *.*proj file (corresponding to a SonarQube module) can override:
A property defined in the command line (/d:propertyName=value) has which can override:
A property defined in the SonarQube.Analysis.xml configuration file
A property defined in the SonarQube User Interface at project level which can override everything
A property defined in the SonarQube User Interface at global level which can't override anything
To exclude specific folders or extensions from your Solution:
You need to add the excludes into each individual projects' .csproj file. Here's the syntax which you should use within the main root node, called <Project...> and into one of the targets, preferably <Target Name="BeforeBuild">. Hope the syntax below is self-explanetory enough, but in case it isn't, please leave a comment under this answer and I'll update it right away.
<Target Name="BeforeBuild">
<ItemGroup>
<SonarQubeSetting Include="sonar.exclusions">
<Value>**/Databases/**/*</Value>
</SonarQubeSetting>
</ItemGroup>
</Target>
Hope it helps!
Source
I am new to MSBuild. Just started trying it two days ago, and now I am just testing it. I have run into a problem where I get this error:
"c:\Users\martinslot\Documents\Visual Studio 2010\Projects\MultifileAssembly\SpecializedBuild.xml" (BuildNumberUtil target) (1) ->
c:\Users\martinslot\Documents\Visual Studio 2010\Projects\MultifileAssembly\SpecializedBuild.xml(4,34): error MSB4006: There is a circular dependency in t
he target dependency graph involving target "BuildNumberUtil".
My MSBuild script look like this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BuildNumberUtil" DependsOnTargets="BuildStringUtil" >
<Message Text="=============Building modules for NumberUtil============="/>
<Csc TargetType="Module" Sources="NumberUtil/DoubleUtil.cs; NumberUtil/IntegerUtil.cs" AddModules="/StringUtil/StringUtil"/>
<Copy SourceFiles="#(NetModules)" DestinationFolder="../Output/Specialized"/>
</Target>
<Target Name="BuildStringUtil" DependsOnTargets="BuildNumberUtil" >
<Message Text="=============Building modules for StringUtil============="/>
<Csc TargetType="Module" Sources="StringUtil/StringUtil.cs;" AddModules="/NumberUtil/IntegerUtil;/NumberUtil/DoubleUtil"/>
<Copy SourceFiles="#(NetModules)" DestinationFolder="/Output/Specialized"/>
</Target>
</Project>
I understand the problem, actually I created this small example to see if MSBuild understood and could somehow correct the problem. How do I solve this?
My problem is that the two targets compile modules that rely on eachother. Does someone here have a solution on how to handle this kind of problem with MSBuild? Maybe I am constructing this in the wrong way?
You simply cannot build projects with circular dependencies. How could you? Which do you build first? There may be some esoteric, convoluted, incorrect way of doing so, but why do it? Circular dependencies usually indicate a design flaw. Fix the design, and you no longer have a circular dependency issue.
It is possible to construct Circular Modules within the scope of MSBuild and Visual Studio; however, doing so has a very limited set of situations where it would be valid to do so.
One key way to do this, if you're planning on using Xaml within your code, is to remove the Sources aspect of the Csc tag and generate your own .response file which actually points to the code you wish to inject. Within the Csc tag attributes you'd specify this file yourself in the ResponseFiles attribute.
Within your .response file, you would then break your application down into its assembly and netmodule components, making sure to include the core assembly's files first at all times. Typically the Csc tag's attributes are directly translated into Csc.exe command line parameters. The parameter names do not always match up. For the sake of resolution it's best to use full, non-relative, paths when referring to files (example, partial, .response below):
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\SearchContexts\StringSearchType.cs"
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\UI\Themes\Themes.cs"
/target:module /out:bin\x86\Debug\InternalName.UI.dll
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\UI\EditDatabaseImageControl.xaml.cs"
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\obj\x86\Debug\UI\EditDatabaseImageControl.g.cs"
You'll notice that this will end up with merging your multiple sets of Targets into one, and that I've included the xaml generated code myself. This is partly why you remove the Sources aspect, as the Xaml Page generator part of the MSBuild task automatically injects information into the #(Compile) set. Since there's a Debug/Release configuration, in the area where you define the response file to use, I create two versions of the response (since I'm using a T4 template):
ResponseFiles="$(CompilerResponseFile);InternalName.$(Configuration).response"
If you intended to include more than one platform in your code you'd likely need C*P response files where C is the number of configurations (Debug|Release) and P is the number of platforms (x86, x64, AnyCpu). This kind of solution would likely only be a sane method by using a generator.
The short version of this: it is possible to create circular modules so long as you can guarantee that you'll compile it all in one step. To ensure that you maintain the build functionality that is afforded to you with the Xaml build step, your best bet is to start with a normal C# project, and create your own .Targets file from the $(MSBuildToolsPath)\Microsoft.CSharp.targets in the <Import ... tag near the bottom. You'll also likely need a secondary csproj for design purposes since a large portion of intellisense is lost by using this workaround (or use a csproj Condition attribute where the target is selected by some flag you set). You'll also notice certain Xaml editors don't seem to like the binding to netmodule namespaces, so if you bind to types in a netmodule you'll likely have to do them in codebehind (I haven't tested workarounds for this since there's usually ways around static namespace binding)
For some reason within all this, the .baml compiled .xaml files are implicitly understood by the Csc compiler, I haven't been able to figure out where it's deriving this from a command argument, or if it's just implicit by design. If I had to guess they're inferred by the g.cs files associated to what you include in your list of included files.
Observe that this is occurred for web application (either ASP.NET standard web application or ASP.NET MVC application) and fix for this problem is to be removed the below line in ".csproj" file.
<PropertyGroup>
<BuildDependsOn>
$(BuildDependsOn);
Package
</BuildDependsOn>
</PropertyGroup>
Original Problem
In building our projects, I want the mercurial id of each repository to be embedded within the product(s) of that repository (the library, application or test application).
I find it makes it so much easier to debug an application being run by customers 8 timezones away if you know precisely what went into building the particular version of the application they are using. As such, every project (application or library) in our systems implements a way of getting at the associated revision information.
I also find it very useful to be able to see if an application has been compiled with clean (un-modified) changesets from the repository. 'Hg id' usefully appends a + to the changeset id when there are uncommitted changes in a repository, so this allows us to easily see if people are running a clean or a modified version of the code.
My current solution is detailed below, and fulfills the basic requirements, but there are a number of problems with it.
Current Solution
At the moment, to each and every Visual Studio solution, I add the following "Pre-build event command line" commands:
cd $(ProjectDir)
HgID
I also add an HgID.bat file to the Project directory:
#echo off
type HgId.pre > HgId.cs
For /F "delims=" %%a in ('hg id') Do <nul >>HgID.cs set /p = #"%%a"
echo ; >> HgId.cs
echo } >> HgId.cs
echo } >> HgId.cs
along with an HgId.pre file, which is defined as:
namespace My.Namespace {
/// <summary> Auto generated Mercurial ID class. </summary>
internal class HgID {
/// <summary> Mercurial version ID [+ is modified] [Named branch]</summary>
public const string Version =
When I build my application, the pre-build event is triggered on all libraries, creating a new HgId.cs file (which is not kept under revision control) and causing the library to be re-compiled with with the new 'hg id' string in 'Version'.
Problems with the current solution
The main problem is that since the HgId.cs is re-created at each pre-build, so every time we need to compile anything, all projects in the current solution are re-compiled. Since we want to be able to easily debug into our libraries, we usually keep many libraries referenced in our main application solution. This can result in build times which are significantly longer than I would like.
Ideally I would like the libraries to compile only if the contents of the HgId.cs file have actually changed, as opposed to having been re-created with exactly the same contents.
The second problem with this method is it's dependence on specific behaviour of the windows shell. I've already had to modify the batch file several times, since the original worked under XP but not Vista, the next version worked under Vista but not XP and finally I managed to make it work with both. Whether it will work with Windows 7 however is anyones guess and as time goes on, I see it more likely that contractors will expect to be able to build our apps on their Windows 7 boxen.
Finally, I have an aesthetic problem with this solution, batch files and bodged together template files feel like the wrong way to do this.
My actual questions
How would you solve/how are you solving the problem I'm trying to solve?
What better options are out there than what I'm currently doing?
Rejected Solutions to these problems
Before I implemented the current solution, I looked at Mercurials Keyword extension, since it seemed like the obvious solution. However the more I looked at it and read peoples opinions, the more that I came to the conclusion that it wasn't the right thing to do.
I also remember the problems that keyword substitution has caused me in projects at previous companies (just the thought of ever having to use Source Safe again fills me with a feeling of dread *8').
Also, I don't particularly want to have to enable Mercurial extensions to get the build to complete. I want the solution to be self contained, so that it isn't easy for the application to be accidentally compiled without the embedded version information just because an extension isn't enabled or the right helper software hasn't been installed.
I also thought of writing this in a better scripting language, one where I would only write HgId.cs file if the content had actually changed, but all of the options I could think of would require my co-workers, contractors and possibly customers to have to install software they might not otherwise want (for example cygwin).
Any other options people can think of would be appreciated.
Update
Partial solution
Having played around with it for a while, I've managed to get the HgId.bat file to only overwrite the HgId.cs file if it changes:
#echo off
type HgId.pre > HgId.cst
For /F "delims=" %%a in ('hg id') Do <nul >>HgId.cst set /p = #"%%a"
echo ; >> HgId.cst
echo } >> HgId.cst
echo } >> HgId.cst
fc HgId.cs HgId.cst >NUL
if %errorlevel%==0 goto :ok
copy HgId.cst HgId.cs
:ok
del HgId.cst
Problems with this solution
Even though HgId.cs is no longer being re-created every time, Visual Studio still insists on compiling everything every time. I've tried looking for solutions and tried checking "Only build startup projects and dependencies on Run" in Tools|Options|Projects and Solutions|Build and Run but it makes no difference.
The second problem also remains, and now I have no way to test if it will work with Vista, since that contractor is no longer with us.
If anyone can test this batch file on a Windows 7 and/or Vista box, I would appreciate hearing how it went.
Finally, my aesthetic problem with this solution, is even stronger than it was before, since the batch file is more complex and this there is now more to go wrong.
If you can think of any better solutions, I would love to hear about them.
I've just released a small open-source MSBuild task to do exactly what you need:
It puts your Mercurial revision number into your .NET assembly version
You can tell from the version if an assembly has been compiled with uncommitted changes
Does not cause unnecessary builds if the revision hasn't changed
Not dependent on Windows scripting
Nothing to install - you just add a small DLL to your solution, and edit some files in your project
http://versioning.codeplex.com
I think I have an answer for you. This will be a bit involved, but it gets you away from having to do any batch files. You can rely on MSBuild and Custom Tasks to do this for you. I've used the extension pack for MSBuild (Available at CodePlex) - but the second task you need is something you could just as easily write yourself.
With this solution, you can right click on the DLL and see in the file properties which Mercurial Version the DLL (or EXE) came from.
Here are the steps:
Get the MBBuildExtension Pack
OR Write Custom Task to overwrite
AssemblyInfo.cs
Create a Custom
Build Task in its own project to get
the Mercurial Id(code below).
Edit project files that need the
Mercurial Id to use Custom Task
(code below).
Custom Task to Get mercurial id: (This would need to be tested well and perhaps better generalized...)
using System;
using System.Diagnostics;
using Microsoft.Build.Utilities;
using Microsoft.Build.Framework;
namespace BuildTasks
{
public class GetMercurialVersionNumber : Task
{
public override bool Execute()
{
bool bSuccess = true;
try
{
GetMercurialVersion();
Log.LogMessage(MessageImportance.High, "Build's Mercurial Id is {0}", MercurialId);
}
catch (Exception ex)
{
Log.LogMessage(MessageImportance.High, "Could not retrieve or convert Mercurial Id. {0}\n{1}", ex.Message, ex.StackTrace);
Log.LogErrorFromException(ex);
bSuccess = false;
}
return bSuccess;
}
[Output]
public string MercurialId { get; set; }
[Required]
public string DirectoryPath { get; set; }
private void GetMercurialVersion()
{
Process p = new Process();
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.RedirectStandardError = true;
p.StartInfo.CreateNoWindow = true;
p.StartInfo.WorkingDirectory = DirectoryPath;
p.StartInfo.FileName = "hg";
p.StartInfo.Arguments = "id";
p.Start();
string output = p.StandardOutput.ReadToEnd().Trim();
Log.LogMessage(MessageImportance.Normal, "Standard Output: " + output);
string error = p.StandardError.ReadToEnd().Trim();
Log.LogMessage(MessageImportance.Normal, "Standard Error: " + error);
p.WaitForExit();
Log.LogMessage(MessageImportance.Normal, "Retrieving Mercurial Version Number");
Log.LogMessage(MessageImportance.Normal, output);
Log.LogMessage(MessageImportance.Normal, "DirectoryPath is {0}", DirectoryPath);
MercurialId = output;
}
}
And the modified Project File: (The comments may help)
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!--this is the import tag for the MSBuild Extension pack. See their documentation for installation instructions.-->
<Import Project="C:\Program Files (x86)\MSBuild\ExtensionPack\MSBuild.ExtensionPack.tasks" />
<!--Below is the required UsingTask tag that brings in our custom task.-->
<UsingTask TaskName="BuildTasks.GetMercurialVersionNumber"
AssemblyFile="C:\Users\mpld81\Documents\Visual Studio 2008\Projects\LambaCrashCourseProject\BuildTasks\bin\Debug\BuildTasks.dll" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>9.0.30729</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{D4BA6C24-EA27-474A-8444-4869D33C22A9}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>LibraryUnderHg</RootNamespace>
<AssemblyName>LibraryUnderHg</AssemblyName>
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.Core">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
<Reference Include="System.Xml.Linq">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
<Reference Include="System.Data.DataSetExtensions">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
<Reference Include="System.Data" />
<Reference Include="System.Xml" />
</ItemGroup>
<ItemGroup>
<Compile Include="Class1.cs" />
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="Build" DependsOnTargets="BeforeBuild">
<!--This Item group is a list of configuration files to affect with the change. In this case, just this project's.-->
<ItemGroup>
<AssemblyInfoFiles Include="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs" />
</ItemGroup>
<!--Need the extension pack to do this. I've put the Mercurial Id in the Product Name Attribute on the Assembly.-->
<MSBuild.ExtensionPack.Framework.AssemblyInfo AssemblyInfoFiles="#(AssemblyInfoFiles)"
AssemblyProduct="Hg: $(MercurialId)"
/>
<!--This is here as an example of messaging you can use to debug while you are setting yours up.-->
<Message Text="In Default Target, File Path is: #(AssemblyInfoFiles)" Importance="normal" />
</Target>
<Target Name="BeforeBuild">
<!--This is the custom build task. The Required Property in the task is set using the property name (DirectoryPath)-->
<BuildTasks.GetMercurialVersionNumber DirectoryPath="$(MSBuildProjectDirectory)">
<!--This captures the output by reading the task's MercurialId Property and assigning it to a local
MSBuild Property called MercurialId - this is reference in the Build Target above.-->
<Output TaskParameter="MercurialId" PropertyName="MercurialId" />
</BuildTasks.GetMercurialVersionNumber>
</Target>
<!--<Target Name="AfterBuild">
</Target>-->
</Project>
Last Note: The build tasks project only needs to be built once. Don't try to build it every time you do the rest of your solution. If you do, you will find that VS2008 has the dll locked. Haven't figured that one out yet, but I think the better thing to do is build the dll as you want it, then distribute ONLY the dll with your code, ensuring that the dll's location is fixed relative to every project you need to use it in. That way, no one has to install anything.
Good luck, and I hope this helps!
Audie
Have you considered using a string resource instead of a C# language string constant? String resources can be edited/replaced in the output binaries post-build using tools intended for localization.
You would emit your mercurial version number to a text file that is not used by the C# build, then using a post-build operation replace the version resource with the actual value from the emitted text file. If you strong-name sign your assemblies, the resource string replacement would need to happen before the signing.
This is how we handled this issue at Borland years ago for Windows products. The world has become more complicated since then, but the principle still applies.
Im my .hgrc I have this:
[extensions]
hgext.keyword =
hgext.hgk =
[keyword]
** =
[keywordmaps]
Id = {file|basename},v {node|short} {date|utcdate} {author|user}
And in my source file (Java) I do:
public static final String _rev = "$Id$";
After commit $Id$ gets expanded into something like:
public static final String _rev = "$Id: Communication.java,v 96b741d87d07 2010/01/25 10:25:30 mig $";
We have solved this issue with another source control system, subversion.
What we do is that we have a commonassemblyinfo.cs file and we plug the svn revision number into that using an msbuild script.
We literally call svninfo and scrape the output from the revision: part and then poke it into the CommonAssemblyInfo.cs file.
Every project in our solution has a link to the common file and is then compiled, meaning that the assemblies are versioned on compilation with the svn revision number, it also means all dependent libraries we have written are also versioned.
We acheived this quite easily using cruisecontrol .net and msbuild files.
I have not used mercurial but I beleive you could do something similar with the id command ?
but because of the format of the output you would need to approach how you used it somewhat differently.
I would have a standard xml file that is read on app startup and you could poke the information into that (works for resx files also). You can then read that value back out in code. A bit icky but it works.
My favourite solution is the way we do it but you can't do that in mercurial as the changeset info is not purely numeric like the svn revision number is.
There seems to be multiple possible approaches to this problem. The first and probably preferred solution would be to install a build server and only distribute builds generated there to customers. This has the advantage that you never ship uncommitted changes. By using MSBuild, NAnt or some other task-based build tool the entire process is very flexible. I was able to install TeamCity and get the first couple of builds up and running with very little effort, but there are other good build servers too. This really should be your solution.
If you for some reason insist that it's okay to distribute developer builds to clients ;) then you'll need a local solution.
A fairly easy solution would be to use the built-in support for auto-incrementing the build number of an assembly:
// major.minor.build.revision
[assembly:AssemblyVersion("1.2.*")]
The * makes the build number auto-increment every time you compile (and there are changes). The revision number is a random number. From here you can either keep track of the association to the Mercurial id by saving both pieces of information, e.g. by posting it to some internal web solution or whatever fits your particular needs, or update the generated assembly. I'd suspect you could use PostSharp or Mono.Cecil do rewrite the assembly, e.g. by patching the revision number to be the id. If your assemblies are signed the rewrite needs to happen before you sign them, which is a bit bothersome if you don't have a build file. Note that VS can be configured to compile using your custom build file instead of the default build procedure.
My final suggestion is to create a separate project just for the hg id, and use the post-build step to merge the generated assemblies into one. ILMerge supports re-signing of signed assemblies and this is therefore likely to be easier to make work. The downside is that redistribution of ILMerge is not allowed (although commercial use is).
It's not a solution but hopefully inspiration to get you going.
Here's what we do here: we do not embed the revision every time the project is built on developer's machines. At best this causes the problems you've mentioned above, and at worst it's misleading because you could have modified files in your workspace.
Instead we only embed the source control revision number when our projects are built under TeamCity on a separate build server. The revision is embedded into both AssemblyVersion and AssemblyFileVersion, split across the last two parts.
By default the version ends in 9999.9999, and we split the revision in such a way that revision 12345678 would become 1234.5678 (not that we're anywhere close to the 12 millionth revision...).
This process guarantees that a product whose version is 2.3.1.1256 was definitely a pristine build of revision 11,256. Anything developers build manually will instead look like this: 2.3.9999.9999.
The exact details of how the above is achieved are not directly relevant since we're not using Mercurial, but briefly: TeamCity handles checking out the required revision and passes its number to our MSBuild script, which then does the rewriting of AssemblyInfo.cs with the help of a custom task we wrote.
What I particularly like about this is that absolutely no files are modified by hitting F5 in Visual Studio - in fact, as far as Visual Studio is concerned, it's working with a plain old normal solution.
I have a solution that contains several c# projects and I would like to be able to set the output path and other properties on all the projects together in a single place. Property Sheets (vsprops) do not seem to be able available for C# projects and the $(SolutionDir) variable is ignored. Are there any other methods to set properties across several C# projects?
Update
By Following the information in the answer by Bas Bossink I was able to set the output path of several projects by creating a common csproj and importing it into the individual project. A few other points:
When building in Visual Studio if changes are made to the common project it is necessary to touch/reload any projects that reference it for the changes to be picked up.
Any properties which are also set in a individual project will override the common properties.
Setting $(SolutionDir) as the output path via the Visual Studio UI does not work as expected because the value is treated as a string literal rather than getting expanded. However, Setting $(SolutionDir) directly into the csproj file with a text editor works as expected.
A csproj file is already an msbuild file, this means that csproj files can also use an import element as described here. The import element is
exactly what you require. You could create a Common.proj that contains something like:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5"xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OutputPath>$(SolutionDir)output</OutputPath>
<WarningLevel>4</WarningLevel>
<UseVSHostingProcess>false</UseVSHostingProcess>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
</Project>
You can import this Common.proj in each of your csprojs, for instance like so:
<Import Project="..\Common.proj" />
The import statement should precede any tasks that depend on the properties defined in Common.proj
I hope this helps. I can't confirm your problems with the $(SolutionDir) variable I've used it many times. I do know however that this variable does not get set when you run an msbuild command via the commandline on a specific project that is contained in a solution. It will be set when you build your solution in Visual Studio.
Unfortunately, these bits of information such as output path are all stored inside the individual *.csproj files. If you want to batch-update a whole bunch of those, you'll have to revert to some kind of a text-updating tool or create a script to touch each of those files.
For things like this (apply changes to a bunch of text files at once) I personally use WildEdit by Helios Software - works like a charm and it's reasonably priced.
But I'm sure there are tons of free alternatives out there, too.
I would suggest you to use a build tool such as MSBuild or NAnt which would give you more flexibility on your builds. Basically the idea is to kick off a build using (in most cases) a single configurable build file.
I would personally recommend NAnt.
You could find an awesome tutorial on NAnt on JP Boodhoo's blog here
Set the $(OutputPath) property in a common property sheet. Then delete that entry in all the project files you want to it to affect. Then import that property sheet into all your projects.
For hundreds of projects that can be very tedious. Which is why I wrote a tool to help with this:
https://github.com/chris1248/MsbuildRefactor