I have many projects that I have created a common MSBuild file to run against. I am attempting to integrate PVS Studio's static analysis into the build without having it build a second time. I followed a bit of the documentation on PVS's site, but I must be missing something.
I say that because when I build the PVS does not seem to my triggered/called.
Does anybody have any experience with this and could give me a hand?
Here is the PVS bit of my build file.
<UsingTask TaskName="ProgramVerificationSystems.PVSStudio.PVSStudio"
AssemblyFile="C:\Program Files (x86)\PVS-Studio\PVS-Studio-MSBuild.dll" />
<Target Name="PVSStudioAnalysisBeforeCompile" BeforeTargets="ClCompile">
<Exec Command="echo PVSStudio initiating now."/>
<PVSStudio Condition="'%(ClCompile.ExcludedFromBuild)'!='true'"
Sources="#(ClCompile)"
BeforeClCompile="true"
BuildingInIDE="false"
TrackerLogDirectory="%(ClCompile.TrackerLogDirectory)"
PreprocessorPath="$(VCInstallDir)"
Platform="$(Platform)"
ProjectFullPath="$(MSBuildProjectFullPath)"
SolutionDir="$(SolutionDir)">
<Output TaskParameter="SourcesAfterTlogParsing"
ItemName="CLCompileAfterTlogParsing" />
</PVSStudio>
</Target>
<Target Name="PVSStudioAnalysisAfterCompile" AfterTargets="ClCompile">
<PVSStudio Sources="#(CLCompileAfterTlogParsing)"
BeforeClCompile="false"
BuildingInIDE="$(BuildingInsideVisualStudio)"
PreprocessorPath="$(VCInstallDir)"
OutputFilePath ="$(OutputDir)"
Platform="$(Platform)"
ProjectFullPath="$(MSBuildProjectFullPath)"
SolutionDir="$(SolutionDir)" />
<Exec Command="echo PVSStudio finished"/>
I'm sure you all will need a bit more info to figure this out so let me know what I should get for you.
Thanks,
TBG
You should do one of the following:
If you want analyzer's output to be saved to a file, the you should set BuildingInIDE attribute to false in both tasks, you should also specify a file for the output to be saved to, for example, OutputFilePath = "$(OutputDir)"/pvs.log.
You will be able to view such log from PVS-Studio IDE plug-in / Standalone by opening it as unparsed log.
If you want to build your project from inside Visual Studio and PVS-Studio plug-in to hook up the analyzer results to it output window immediately, then you should set both BuildingInIDE attributes to true (or "$(BuildingInsideVisualStudio)") and enable the MSBuild mode by going to PVS-Studio -> Options -> Specific Analyzer Settings -> MSBuild Output Log Monitoring and set it to true.
Related
I am working differentially building a huge monolithic solution that includes about 80 projects. In my build pipeline right now I include a step to build the entire solution. But what I'd like to do is to build the solution but provide conditions as msbuild arguments so that I can exclude some of the projects that might not have any changes associated with them. I already have scripts to go through my commits and realize what changed and which projects need to be built.
I just need a way to send that info to MSBuild so that it does not build all projects everytime. I tried building projects separately but that takes a whole lot more time than just building the solution together.
So, I'm looking for any solutions out there through which I can specify to MSBuild that skip a specific project would help a lot. Thanks much!
I already have scripts to go through my commits and realize what
changed and which projects need to be built.
Since I could get clearly know that which script are you using to realize what changed and which projects need to be built. I am assuming that you are using MSbuildTarget script which in the xx.csproj to do these judgement.
=If I did not have misunderstanding, you can get help from this similar issue (See ilya's answer).
See this document and you'll find the build action is performed by these three targets, BeforeBuild,CoreBuild and AfterBuild. So assuming you have a target to go through my commits and realize what changed and if a project need to be built, you can add script like below to xx.csproj:
<PropertyGroup>
<BuildWrapperDependsOn>$(BuildDependsOn)</BuildWrapperDependsOn>
<BuildDependsOn>CheckIfBuildIsNeeded;BuildWrapper</BuildDependsOn>
</PropertyGroup>
<Target Name="CheckIfBuildIsNeeded">
<!-- Execute command here that checks if proceed with the build and sets the exit code -->
<Exec Command="exit /b 1" WorkingDirectory="$(SourcesPath)" IgnoreExitCode="true">
<Output TaskParameter="ExitCode" PropertyName="ExecExitCode"/>
</Exec>
<Message Text="Exit Code: $(ExecExitCode)" Importance="high" />
<PropertyGroup Condition="'$(ExecExitCode)' == '1'">
<DoBuild>false</DoBuild>
</PropertyGroup>
</Target>
<Target Name="BuildWrapper" Condition=" '$(DoBuild)' != 'false' " DependsOnTargets="$(BuildWrapperDependsOn)" Returns="$(TargetPath)" />
Above is the script from ilys, and hope my description can help you understand it. With this script, when we start a build target, it will firstly run the targets it depends on, so it will run the CheckIfBuildIsNeeded target and BuildWrapper target. And only when the DoBuild property is true, the BuildWrapper will actually execute. And since buildwrapper depends on original $(BuildDependsOn), it will continue the real build process.
The total logic is: Run CheckIfBuildIsNeeded script and output value to indicates whether need to build=>Try to Run BuildWrapper=>IF need to build, then run the real build success(BeforeBuild, Corebuild,Afterbuild), if the value is false, finish the build process. So I think you can do some little changes to this script then it can work for your situation. (Not sure what your script looks like, I can't complete it for you)
And since you have many projects, you don't need to add this script to every project manually. You can create a Directory.Build.props file, copy the script into it, and place the file in solution folder, then it will work for all projects in the solution.
I've written a MSBuild project files which try to build in parallel all the configs of my VS2010 solution:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<ItemGroup>
<BuildFile Include="$(SourceRoot)MyProject.sln" />
<Config Include="Debug">
<Configuration>Debug</Configuration>
</Config>
<Config Include="Release">
<Configuration>Release</Configuration>
</Config>
</ItemGroup>
<Target Name="BuildAll" Outputs="%(Config.Configuration)">
<Message Text="Start building for configuration: %(Config.Configuration)" />
<MSBuild Projects="#(BuildFile)"
Properties="Configuration=%(Config.Configuration)"
Targets="Build" />
</Target>
</Project>
And I launch msbuild with:
msbuild /m /p:BuildInParallel=true /t:BuildAll buildall.proj
The problem is that my solution have many .Net projects which all have the same output folder. These projects use also the same external assemblies.
So very often, two output executables are generated at the same time and their dependencies copied at the same time. This leads to errors like:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3001,9):
error MSB3021:
Unable to copy file "xxx\NLog.dll" to "D:\src\Blackbird\shared\bin\debug\NLog.xml". The process
cannot access the file 'xxx\NLog.dll because it is being used by another process.
which I think means: "2 different projects use NLog and try to copy its assembly in the output folder at the same time"...
Is there a way to get around that? I really would like to avoid to modify all the projects in the solution.
Looking at the task source code "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3001,9)", I've seen that it is possible to make msbuild retry the copy:
<Copy
SourceFiles="#(ReferenceCopyLocalPaths)"
DestinationFiles="#(ReferenceCopyLocalPaths->'$(OutDir)%(DestinationSubDirectory)%(Filename)%(Extension)')"
SkipUnchangedFiles="$(SkipCopyUnchangedFiles)"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
UseHardlinksIfPossible="$(CreateHardLinksForCopyLocalIfPossible)"
Condition="'$(UseCommonOutputDirectory)' != 'true'"
>
I've try to set the variables CopyRetryCount, CopyRetryDelayMilliseconds, ... I was hoping that if the copy fails, another copy done a few milliseconds later would succeed. But I've been unable to set these parameters. How can I change them?
Is there another solution?
I've found the solution
<MSBuild Projects="#(BuildFile)"
Properties="Configuration=%(Config.Configuration);Retries=10;RetryDelayMilliseconds=50"
Targets="Build" />
It works as expected but now it generates a warning before retrying the copy
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3001,9):
warning MSB3026: Could not copy
"D:\src\xxx\System.Data.SQLite.pdb" to "..\Debug\System.Data.SQLite.pdb".
Beginning retry 1 in 50ms. The process cannot access the file
'..\Debug\System.Data.SQLite.pdb' because it is being used by another process.
During my last test, it generated 36 times this warning! Is there a way for suppressing the warning MSB0326?
In general, anything that runs during build must not acquire an exclusive lock on its inputs - only shared-read lock. It appears that something in your build process (probably NLog, whatever that is) violates this - it takes exclusive lock on the input "xxx\NLog.dll", so when another msbuild node tries to copy the same input it fails.
Retry is a reasonable workaround for the particular symptom you have - though it's not guaranteed to always succeed.
I had the same problem. I needed to add appropriate exception to my AntiVirus to avoid sacanning DLLs produced by MsBuild.
I am trying to set/override some settings in our TEST installation of TFS with regards to forcing Code Analysis and assosicated settings during the build process (regardless of the setting sin the project file)
We currently use in our TEST TFS installation:
Visual Studio 2012 Ultimate on our developer machines AND build server
Have TFS 2012 installed on one server (application and data layer)
Have TFS 2012 build service (controller and agent) installed on another server
We can compile sample .net 4.5 projects (class libraries (DLLs), web applications etc) as expected. This is solely to do with overriding associated Code Analysis settings (hopefully).
Scenario 1 - In our sample applications on our developer machines when you select the project settings (right click -> properties in solution explorer), go to the Code Analysis tab if I turn on the "Enable Code Analysis on build" and select a Rule set from the drop down is performs as exepcted, hence it will generate some warnings. This technical adds <RunCodeAnalysis>false</RunCodeAnalysis> to the *.csproj file if opened up in notepad. If the build is executed to compile the sample project/solution then Code Analysis is performed as expected. I do NOT want to do this on every project because a developer could turn it off (although I am looking to have check-in policies and/or private/gated checkins as well to force this anyway).
Scenario 2 - I can disable the "Enable Code Analysis on Build" checkbox and force code analysis in our TFSBuild.proj file (we (will) use the default upgradetemplate.xaml as our process definition because we will be upgrading from TFS 2008 on our LIVE TFS installation) by having:
<RunCodeAnalysis>Always</RunCodeAnalysis>
This works and this is how we will force (lessons still to be learned :-)) Code Analysis on our builds.
The problem then comes when setting other assosicated Code Analysis settings. For example which default rule set(s) to apply/use or treat CA warnings as errors. Some of these settings can be set either in VS or all of them by editting *.csproj in notepad. If i edit the *.csproj then these values are used in the build as expected (as well as locally on the developer machine). This is not ideal as I want to do it centrally in TFSBuild.proj without having to edit every project file. I believe I can use settings such as in my TFSbuild.proj file:
<PropertyGroup>
<RunCodeAnalysis>Always</RunCodeAnalysis>
<CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
</PropertyGroup>
But they don't appear to work or I am putting them in the wrong place? How do I fix/use them correctly?
FYI i build my solutions in TFSBuild.proj by:
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ItemGroup>
<SolutionToBuild Include="/some folder/some solution.sln" />
<ConfigurationToBuild Include="Debug|Any CPU">
<FlavorToBuild>Debug</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
</Project>
On the build server I did find reference to the target file for Code Analysis at c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\CodeAnalysis but I dont want to change the default behaviour on the build server (although it does work when I do). The condition for example for CodeAnalysisTreatWarningsAsErrors must be getting evaluated as false. Its like my values are not read from TFSBuild.proj but are from the .csproj file.
Any questions feel free to ask and thanks in advance
I had what I think is a similar problem with Cruise Control not compiling using the CODE_ANALYSIS compilation symbol, even if "Enable Code Analysis on Build (defines CODE_ANALYSIS constant)" was checked in VS.Net.
It looks like whether it is check or not, CODE_ANALYSIS is actually not explicitly added to the list of compilation symbols in the csproj (even if it appears in the text box "Conditional compilation symbols"), only <RunCodeAnalysis>true</RunCodeAnalysis> is added.
When compiling through VS.Net, the CODE_ANALYSIS is automatically added, but not when using MSBuild, which is what Cruise Control uses.
I eventually changed in VS.Net the "Conditional compilation symbols" from "CODE_ANALYSIS;MySymbol" to "MySymbol;CODE_ANALYSIS". Doing that forced CODE_ANALYSIS to also appear in the csproj.
I remember having a similar problem - but not having the time to investigate it, I worked around it by calling FxCop directly using the exec task. I'll just give you the highlights, omitting the specification of some properties, I hope the names are clear.
I created an ItemGroup of the output dlls, FilesToAnalyze, and fed it to FxCop in a way similar to:
<PropertyGroup>
<FxCopErrorLinePattern>: error</FxCopErrorLinePattern>
<FxCopCommand>"$(FxCopPath)" /gac /rule:"$(FxCopRules)" /ruleset:="$(FxCopRuleSet)" #(FilesToAnalyze->'/file:"%(identity)"', ' ') /out:$(FullFxCopLog) /console | Find "$(FxCopErrorLinePattern)" > "$(FxCopLogFile)"</FxCopCommand>
</PropertyGroup>
<Exec Command="$(FxCopCommand)"
ContinueOnError="true">
<Output TaskParameter="ExitCode" PropertyName="FxCopExitCode"/>
</Exec>
<ReadLinesFromFile File="$(FxCopLogFile)">
<Output TaskParameter="Lines" ItemName="AllErrorLines"/>
</ReadLinesFromFile>
I could then determine the number of errors in the output using an extensionpack task:
<MSBuild.ExtensionPack.Framework.MsBuildHelper TaskAction="GetItemCount" InputItems1="#(AllErrorLines)">
<Output TaskParameter="ItemCount" PropertyName="FxErrorCount"/>
</MSBuild.ExtensionPack.Framework.MsBuildHelper>
and create a failing build step for each error:
<BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Id="$(FxCopStep)"
Status="Failed"
Message="FxCop Failed: $(FxErrorCount) errors."/>
<BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Status="Failed"
Message="%(AllErrorLines.Identity)"/>
By doing code analysis on the build server this way, we also avoided having to configure each project separately. We isolated all this in a separate .targets file, so adding code analysis to a solution was a matter of importing that file, and perhaps adjusting the behavior by setting appropriate properties.
VS 2010; TFS 2010; ASP.Net 4.0; Web Deployment Projects 2010;
I am using the build process templates in order to do one-click deploys (for dev and QA only). I want my sites to be pre-compiled. I can do it with the command line, using:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler
-v /site_name
-p "C:\...\site_name"
-f "C:\...\site_name1"
and this works fine if I copy the files over from site_name1 to site_name...
but is there an option in the IDE for this?? It seems really silly to have to do this from the command line. I've read a lot about different options, but none seem applicable to building with the build definitions.
You can do this by adding the following to your .csproj file
<PropertyGroup>
<PrecompileVirtualPath>/whatever</PrecompileVirtualPath>
<PrecompilePhysicalPath>.</PrecompilePhysicalPath>
<PrecompileTargetPath>..\precompiled</PrecompileTargetPath>
<PrecompileForce>true</PrecompileForce>
<PrecompileUpdateable>false</PrecompileUpdateable>
</PropertyGroup>
<Target Name="PrecompileWeb" DependsOnTargets="Build">
<Message Importance="high" Text="Precompiling to $(PrecompileTargetPath)" />
<GetFullPath path="$(PrecompileTargetPath)">
<Output TaskParameter="fullPath" PropertyName="PrecompileTargetFullPath" />
</GetFullPath>
<Message Importance="high" Text="Precompiling to fullpath: $(PrecompileTargetFullPath)" />
<GetFullPath path="$(PrecompilePhysicalPath)">
<Output TaskParameter="fullPath" PropertyName="PrecompilePhysicalFullPath" />
</GetFullPath>
<Message Importance="high" Text="Precompiling from fullpath: $(PrecompilePhysicalFullPath)" />
<AspNetCompiler PhysicalPath="$(PrecompilePhysicalPath)" VirtualPath="$(PrecompileVirtualPath)" TargetPath="$(PrecompileTargetPath)" Debug="true" Force="$(PrecompileForce)" Updateable="$(PrecompileUpdateable)" FixedNames="true" />
Then in TFS2010's default template
your build definition
Process tab
Advanced parameters section
MSBuild Arguments
set /target="PrecompileWeb"
As it currently stands, I can not find any IDE option to pre-compile websites using the build process templates. I would love to be proved wrong, as using the command line aspnet_compiler requires us (in our setup) to crack open the actual build process template, which we are trying to avoid.
I would love to be proved wrong! :)
We have a website that is stored in TFS2010 as a Web application. I use a MSBuild command to deploy from TFS2010. If you open your project in VS2010 Team Explorer you will see there is a "Builds" option. If you add a build and in the process tab use a build argument like ...:/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=RemoteAgent /p:MSDeployServiceUrl=http://111.111.111.111/msdeployagentservice /p:DeployIisAppPath=MySiteNameInIIS /p:UserName=myDomain\BuildUser /p:Password=BuildUserPassword In the Process tab where it says "Items to Build" you just point it to your .sln file (might work with a .cspro but then the syntax changes slightly)
We have a TFS2010 server and I deploy a few of our sites to a dev, qa, pre-production or production IIS server. I do unit testing on the dev build and if the test fail then I do not deploy.
The MSBuild command does the pre-compile, would that work for you?
A setting for precompiling has been added. The following works in Visual Studio 2015
Open a solution
Right click on the project
Select "Publish..."
Go to settings, expand "File
Check "Precompile during Publishing"
There are plenty of guides out there which help you mimic VS2008's "Custom Build Step" in VS2010 with MSBuild. However, I'd like my build to be smarter and make use of MSBuild. I've written a little MSBuild task which invokes the ANTLR parser generator. That build task works flawlessly when I run it in a simple test MSBuild file. However, when I try to add my task to a C++ project, I run into problems. Essentially I've added this to the top of my project file (Right after the <project> element):
<UsingTask TaskName="ANTLR.MSBuild.AntlrGrammar"
AssemblyName = "ANTLR.MSBuild, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d50cc80512acc876" />
<Target Name="BeforeBuild"
Inputs="ConfigurationParser.g"
Outputs="ConfigurationParserParser.h;ConfigurationParserParser.cpp;ConfigurationParserLexer.h;ConfigurationParserLexer.cpp">
<AntlrGrammar
AntlrLocation="$(MSBuildProjectDirectory)Antlr.jar"
Grammar="ConfigurationParser.g"
RenameToCpp="true" />
</Target>
However, my target is not being called before build.
How can I add my task to a C++ build?
Before reading this answer, you'll probably want to see:
General .vcxproj File Reference
The New Way of doing Build Extensibility in .NET 4
The old way of extending MSBuild, and the one mentioned by the reference book I have, essentially is based on overriding default-empty targets supplied by Microsoft. The new way, as specified in the second link above, is to define your own arbitrary target, and use the "BeforeTargets" and "AfterTargets" properties to force your target to run before or after your intended target.
In my specific case, I needed the ANTLR Grammars task to run before the CLCompile target, which actually builds the C++ files, because the ANTLR Grammars task builds .cpp files. Therefore, the XML looks like this:
<Project ...
<!-- Other things put in by VS2010 ... this is the bottom of the file -->
<UsingTask TaskName="ANTLR.MSBuild.AntlrGrammar"
AssemblyName = "ANTLR.MSBuild, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d50cc80512acc876" />
<Target Name="AntlrGrammars"
Inputs="Configuration.g"
Outputs="ConfigurationParser.h;ConfigurationParser.cpp;ConfigurationLexer.h;ConfigurationLexer.cpp"
BeforeTargets="ClCompile">
<AntlrGrammar
AntlrLocation="$(MSBuildProjectDirectory)\Antlr.jar"
Grammar="Configuration.g"
RenameToCpp="true" />
</Target>
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
</Project>
As for why this is superior to a PreBuildEvent and/or PostBuildEvent; this is smart enough to not rebuild the .cpps when the grammar itself is not updated. You'll get something like:
1>AntlrGrammars:
1>Skipping target "AntlrGrammars" because all output files are up-to-date with respect to the input files.
1>ClCompile:
1> All outputs are up-to-date.
1> All outputs are up-to-date.
This also silences Visual Studio's incessant complaining every time you run the program that it needs to rebuild things, like it does with plain pre- and post- build steps.
Hope this helps someone -- took me frickin forever to figure out.