it's probably a stupid question, but I have wasted a lot of time.
I found this one and several other links where people are editing .xml, .props and .targets file to create a customization in Visual Studio build.
Adding new target to use ClCompile
Here he/she is extending CL rule in xml file and doing other things in .props and .targets file.
But as I am referring to MSBuild documentations, I cannot find a way to customize using these three files. I only found creating a custom target in .vcxproj file. However, when I try to extend a rule here, it just says
Rule is not an element of Project.
These are related documentations I found -
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019
https://learn.microsoft.com/en-us/cpp/build/how-to-add-custom-build-tools-to-msbuild-projects?view=vs-2019
Has methods of adding customization changed or am I not referring to right documentations? Please help. Basically, I want to do what has been done in above stack overflow answer. (Create a preprocessing target which can get all properties/items of CLCompile target.)
I did manage to override ClCompile target by adding ClCompile.props and added my custom task in it by using Exec Command. It served my purpose and I didn't actually go through extending xml file.
Related
So that every time I create a project using the libraries I usually use I won't have to manually add the sheet.
You can do this, but I advise against it. Main reason being it will make your project files unusable on other machines unless you also force your solution on them. Second reason you cannot expect all your projects ever are going to use the same libraries/versions/configurations of those libraries so after a while it might become unmaintainable.
You are imo better of creating a small utility which copies a project from a template you create with all imports and then changes guid and project name. Or create a template for VS which does that.
Anyway: a possible solution is to add an msbuild file which imports all default property sheets you need into the $(VCTargetsPath)\Platforms\Win32\ImportBefore\ directory (create it if it doesn't exist). The file has to have a .targets extension. More info here for example.
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
I finally realized why my BeforeBuild Target is no longer executing as expected -- it's so silly, it's because the project's configuration names had changed. But what I really want to do is test for the solution's configuration name, not the project's.
I know that the project's configuration name is stored in $(Configuration). Is there one for the solution's configuration name? Or is this simply not possible because (presumably) the solution names are only known to the configuration manager? If so, can anyone recommend a good method for managing configurations? I'd hate to have to add duplicate project configuration names everywhere...
UPDATE: after searching and reading some docs, I haven't been able to find any proof that MSBuild is aware of the solution's configuration name when its individual project files are compiled. I went ahead and build the solution from the command line, passing /v:diag, and dumped the output to a file. I searched through the file to find any signs of it knowing that the solution's configuration name is "Deployment", but the only occurences of that string appear when the BeforeBuild condition is checked.
See my other answer. I was able to create a VS extension to get the solution configuration name as a build macro ($(variable) notation).
The only solution I've come up with so far is to create my own environment variable on the TeamCity server, and have MSBuild check for its presence in the BeforeBuild target.
EDIT: I couldn't use my own environment variable because it wasn't getting passed to the build runner for some reason. But when I used /v:n in the TeamCity MSBuild settings, I noticed that there is $(COMPUTERNAME), which is exactly what I wanted anyway. I ended up trying this and it totally did the trick.
There is property SolutionConfigurationContents witch is created by Msbulid during soluton file processing it contains solution configuration in it. When building from VS it will contains project (not solution) configuration.
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.
I need to define a custom build rule for files in my projects.
However the rule may be different for different solutions (more percisely, for the same solution in a parallel dev branch).
I have two questions:
Can a .rules file be specified in a location relative to the solution? That way I'd be able to create rules per development branch.
MSDN says that the custom rule is inheritable similarly to the properties (vsprops). How can that be achieved? Where do I specify the inheritance?
Thanks,
Gil Moses.
.vcproj file will contain the following clause:
<ToolFiles>
<ToolFile
RelativePath="..\my.rules"
/>
</ToolFiles>
You can use $(SolutionDir) to customize placement of the .rules file, like this:
<ToolFiles>
<ToolFile
RelativePath="$(SolutionDir)..\..\..\my.rules"
/>
</ToolFiles>