In Visual Studio 2010 we have MSBuild for C++ project. Also we can add additional custom properties files "*.props" to projects, which are just MSBuild scripts.
Is it possible in imported "some.props" file know its directory?
for example there is "project.vcxproj" file and "common.props" file.
I would like to write something:
<IncludeDir>$( [and something for common.props file directory here] )\include</IncludeDir>
What should I write there?
%programfiles%\msbuild, which is accessible with $(MSBuildExtensionsPath), is the recommended place to put .props and .targets files that you would install and leave static. For example, many Microsoft teams that ship build process put their .targets files there.
If you plan to check-in those .props files for your team to use, or modify them, or maybe have different ones for different sets of source code, it's not such a good location; it isn't next to your source code and it requires admin rights to modify. In such cases, I recommend you put the files near your source code, perhaps at the root of a tree or subtree that includes all the projects for which it is relevant.
If you can put them under %Program Files%/MSBuild/ then you can use the MSBuildExtensionsPath property. This resolves to %Program Files%\MSBuild. If you cannot put the files there then another option would be to create an environment variable. In MSBuild you can access env variables just like properties. For example you can do <Message Text="Path :$(Path)"/> to print out the current path.
Related
I have a Visual Studio solution with over 100 projects in it. I want to apply certain settings to all projects, so I used a Directory.Build.Props file and it works great. However, after reading the documentation I just realized that all of the solutions in the sub directories will use those settings too, but I don't want to affect those solutions since I don't maintain them. Is there a way to limit the scope of a Directory.Build.Props file to the current directory, or a particular solution? (Perhaps you can customize the name of the Props file and import it for a particular solution?)
For example, consider a directory structure organized as such:
/code/MySolutionFile.sln
/code/Project001/
/code/Project002/
/code/Project003/
...
/code/Project100/
/code/OtherStuff/OtherStuff.sln
/code/OtherStuff/ProjectA
/code/OtherStuff/ProjectB
/code/OtherStuff/[lots of other solutions somewhere in this directory tree]
I have put my Directory.Build.Props file in the /code directory because I would like to define settings for all projects in /code/MySolutionFile.sln. But I don't want to affect any of the other solutions in subdirectories of the /code folder.
If all else fails I think I could create an empty Directory.Build.Props file and drop it in every directory that contains a solution file except for the one I want mine to apply to. (But this feels like a last resort.)
Modifying my Directory.Build.props file in this way accomplishes my goal:
<Project>
<PropertyGroup Condition="$(SolutionFileName) == 'MySolution.sln'">
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
</Project>
This works by setting the PropertyGroup to conditionally run the rules. (Note the condition could also be applied to specific rules rather than the group.) In this case I was able to use the name of the solution file to limit the scope of this rule to my desired solution without affecting any others.
One caveat though, the documentation claims that the solution variables are only available when used in the IDE. However, with my limited testing the rules are also correctly applied when I use msbuild from the command line, like this: msbuild.exe MySolution.sln
I tested it from both a VS Developer Command Prompt and a regular Windows Command Prompt, and both still read the $(SolutionFileName) variable properly.
MSBuild supports Conditions on many types of element, including PropertyGroup and individual properties. In this case, you don't need the Choose-When - you could just put the condition on the PropertyGroup or TreatWarningsAserrors directly.
Is there a way to limit the scope of a Directory.Build.Props file to
the current directory, or a particular solution? (Perhaps you can
customize the name of the Props file and import it for a particular
solution?)
The Directory.Build.Props will act on the xxxx.sln of the current folder which contains many included xxxx.csproj files and then also act on the xxxx.proj files of all the sub folders. It will go down one step at a time for any xxx.proj file which it finds and it is designed by that. You can see the search scope of it.
Since your workaround works well but it is a bit complex, or you can try my solution if you are willing to:
Workaround
Please create a folder called MyStuff under the folder code and then put Project001---Project100 into this folder. After that, put your Directory.Build.Props file into MyStuff folder. With it, the file will affect only Project001---Project100.
Hope it could help you.
We have a very large number of solutions spread across a wide number of repositories which do not always share a directory hierarchy in a way that makes it easy for us to update an .editorconfig such that it applies to all projects/solutions in the organization. We currently apply all of our code analysis configuration via an internal NuGet package and I was hoping we could include our organization-wide .editorconfig settings in this way as well?
I tried a quick experiment adding the following to a project to see if linked files would be honored (since we could simply add this to a props file we already have in the NuGet package), but it does not appear to be honored currently.
<ItemGroup>
<None Include="C:\SomeAlternatePath\ECTest\.editorconfig" Link=".editorconfig" />
</ItemGroup>
Is there some other MSBuild property or mechanism we could use to better facilitate this without literally writing a duplicate file to every solution/project/repo?
Is there some other MSBuild property or mechanism we could use to
better facilitate this without literally writing a duplicate file to
every solution/project/repo?
I'm afraid the answer is negative. Cause the .editorconfig file have nothing to do with msbuild or xx.csproj. Only file hierarchy can affect the behavior how the config file works. More details please check this document.
Some tests:
When I right-click project=>add .editorconfig to add this file in current project, there's one line added to the xx.csproj: <None Include=".editorconfig"/>.
If we set the indent_size = 32, it works for current project. Now we can right-click that file=>Exclude from Project to remove that file from current project system. (This action will remove the <None Include=".editorconfig"/> in xx.csproj, but the file is still in the same folder where xx.csproj exists)
Now reload the project, the settings(indent_size=32) still works. So it's obvious if we place this file in project directory, then it will take effect, no matter if we have definitions about it in project file(xx.csproj).
Suggestions:
According to your description, all your projects use the same .editorconfig file. Since this file's working scope is affected by file hierarchy, you can reduce some meaningless work by:
1.Place that file in Solution folder, it will work for all projects under that solution folder
2.Place that file in repos(C:\Users\xxx\source\repos) folder, it will work for all solutions and projects under this folder.
3.So if most of your solutions are under path C:\somepath, place that file here, all projects under that path will benefit from that. And about precedence in file hierarchy please see this one.
Hope all above makes some help :)
I have a custom tool that I run on certain file types using the .targets mechanism in Visual Studio 2015.
Projects exist at many levels, and I want to reference this tool when the code is pulled to ANY drive/folder, including the TFS CI agent.
I tried using a relative path, but because the files are at different levels, it doesn't work for all projects.
I tried using a registry setting and environment variable, but that doesn't bode well for the CI machine which might build in a different folder each time.
Is it possible to get the solution folder of which the project/file is in, then I can use a relative path to the tool directory?
All I can find is these properties, which do not seem to help:
General MSBuild properties:
https://msdn.microsoft.com/en-us/library/bb629394.aspx
https://msdn.microsoft.com/en-us/library/ms164309.aspx
Registry and environment variables:
https://msdn.microsoft.com/en-us/library/ms171458.aspx
You can use all the standard tokens within .targets.
Just use
$(SolutionDir)
See https://msdn.microsoft.com/en-us/library/c02as0cs.aspx
Self-service answer: use visual studio's property editing for a vcxproj in preprocessor macros or include paths or such to look at a bunch of available variables. You can usually find what you need in there, by name, or by example, including the one you need here. Better than any documentation.
We have different dev environments between developers here. When I build, I want my compiled files to be copied to a bin folder located in C:\Web\bin\. Another developer may want those files dropped in C:\Web_2011\bin\.
Using Visual Studio 2010, the way we work this now is to run a BAT file with the directories defined as parameters that need to be changed if pulling from another developer's branch.
Is it possible to store a solution-wide parameter, (in a .user or .suo file maybe,) to define where a developer wants to drop his builds?
You could do it through the project file (.vcxproj for C++ project for example).
The simplest solution would be to add a Custom Build Step that runs some batch file. This batch file could check the current user name and copy the files based on that.
(An even simpler solution would be to run a user specific batch file from his local disk)
If you really want the fully fledged solution that will allow you to save this data to the user file, you can do it by editing the project file and adding a PropertyPageSchema element that extends VS property pages with another parameter (your destination directory). You can define the Persistence attribute of DataSource element as "UserFile" and the data will be saved on your .user file. You will need to add some target that actually uses this data (copies files to the directory specified).
For more information, read about msbuild and PropertyPageSchema.
I have a Visual Studio 2010 project which references some third-party components. Their assemblies are accompanied by XML documentation files, which are useful for us (and only us) developers. And whenever the project is built (either in Debug or Release modes) these XML files are copied to the build directory.
I can't seem to find a setting or switch to disable the copy of those XML files to the build directory, either within Visual Studio or though MSBuild. A post-build script may be an option, but a smelly one. Any ideas? Thank you.
When you build a project the .xml/.pdb files are gathered through the ResolveAssemblyReference task. When ResolveAssemblyReference is called it is passed a list of file extensions for related files. That list of file extensions is captured in the MSBuild property AllowedReferenceRelatedFileExtensions. By default that list will contain ".pdb;.xml".
If you want to exclude all related reference files from being picked up then just override the value of the property to something which related files won't have extensions of. For example you can set AllowedReferenceRelatedFileExtensions to "-".
You can also customize the list of file which are returned by that. If you only want to find only .pdb files then you will need to pass in AllowedReferenceRelatedFileExtensions=".pdb". In that case any references which have .pdb file next to the .dll/.exe they will be copied as well. You can also use this to copy other related files which may not end in .pdb/.xml. For example if you have a referenced assembly named, MyAssembly.dll and in that same folder there exists MyAssembly.pdb and MyAssembly.foo If you set AllowedReferenceRelatedFileExtensions=".pdb;.foo" then both the .pdb and .foo file will be copied to the output directory.
Visual studio project file has the same format as any msbuild file. So you can manually add the condition into corresponding section to not copy your xml files if configuration name is 'Release'.
It should be changing
<ItemGroup>
to
<ItemGroup Condition="'$(CONFIG)'=='RELEASE'">
or something like this.
If the .xml/.pdb are marked as build-action "Content" (etc), you can change them to "None". You should also ensure they copy-to-build-output is false.
Are both of those set?
What is the problem with having the XML files get copied into the folder on release builds? It seems to me that this is fine and that the real problem is with the code that picks up files to place them in the installer. Picking up third party dlls from your own bin\release folder is not a good practice in my opinion. I'd have my installer pick up third party dlls from their own folder in my source tree.
The setting is in the Properties of the project in question, under the "Build" tab, uncheck "XML documentation file". It's also an MSBuild property called <DocumentationFile> under the applicable <PropertyGroup> for your build configuration in the .*proj file.