When I build my solution from the command line using msbuild, I don't get any output from the csharp compiler (Csc) like visual studio does.
For example, if I build my solution in Visual studio I get:
warning CS0162: Unreachable code detected
When I build from command line using msbuild, I get no warning at all (I want the warning to appear!)
Edit: the /verbosity flag does not do the trick
Are you sure you are building the same configuration? Typically Visual Studio will build your Debug configuration by default. MsBuild on the other hand will default to build your Release configuration. Make sure that you have the warning levels set to the same level for both configurations in your project settings.
I think you might need to provide an argument for output verbosity...
From MSDN reference:
Displays this amount of information in the build log. Individual loggers display events based upon the verbosity level. A logger can also be configured to ignore the verbosity setting.
The available verbosity levels are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. /v is also acceptable. For example:
/verbosity:quiet
Related
I have configured a TFS(2017) build pipeline to compile a VS extension with debug mode for a specific requirement which require .pdb files.
The build solution task fails for "debug" configuration with below error, however same pipeline works for the release configuration.
I have tried the approach mentioned in the following discussion as well, howewer it doesn't resolve my issue.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/fd220999-5761-475a-bf86-98dff6b35218/unable-to-compile-vsix-project-that-is-a-part-of-my-solution-using-amd64-msbuild-from-vs2015?forum=msbuild
Appreciate if someone can help me to resolve this issue.
Following is the build configuration used for the Build Solution task:
Following build variables are used to configure build parameters.
Build Error message:
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets
(633, 5)
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets(633,5):
Error VSSDK1077: Unable to locate the extensions directory. "Value
cannot be null. Parameter name: path1". Process 'msbuild.exe' exited
with code '1'.
Update your Microsoft.VSSDK.BuildTools NuGet package to latest version 15.9.3032, just in case it is a problem already solved.
Release configurations can also generate PDB files (Project properties, Build tab, Advanced...button, Output > Debugging information). So, if the Release configuration works for you, you can keep using it while also generating a pdb file with full debug information.
The error is happening when, once compiled correctly, the generated VSIX output file is going to be deployed to the folder for extensions of the experimental VS instance, which is a required step to debug the VSIX file. A possible explanation of the different behavior for Debug/Release configurations is that maybe your .csproj specifies <DeployExtension>False</DeployExtension> for the Release configuration. By default, if not set, that property is set to true in the Microsoft.VsSDK.targets file:
<DeployExtension Condition="'$(DeployExtension)' == ''">true</DeployExtension>
Since likely you don't need to deploy the VSIX to the VS experimental instance when building on a build server (because you are not going to debug it), you can set that property to False to skip the deployment. This can be done with a 3rd build configuration (ex: "DebugBuildServer"), for which you specify DeployExtension to False in the .csproj file, or sticking to two build configurations but passing the /p:DeployExtension=false in the MSBuild arguments of the Visual Studio Build task of your build pipeline.
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.
Simple question. How do I set the build configuration to something other than Debug?
Setting /P:Configuration=Staging in the Command line parameters box, leads to this error:
TeamCity says to use "Build Parameters" instead of "/property:" in an MSBuild step. What does that mean?
So how is it done? I need to build MSDeploy packages for all configurations, I can get the packages to build but everything is Debug.
The way you're doing it is fine -- although perhaps use a lowercase /p:. Our team does it this way too. TeamCity isn't throwing an error, it's just trying to provide some helpful information.
JetBrains provides some documentation for its preferred method at the bottom of the page under Using System Properties in Build Scripts.
I am using the TeamCity Visual Studio runner. I want to add a setting that is not accessible from Visual Studio.
/Property:FileAlignment=4096
I typed that directly into the build step "Command line parameters." The build log shows the error:
MSBuild command line parameters contains "/property:" or "/p:" parameters. Please use Build Parameters instead.
I don't understand how to provide this to MSBuild from TeamCity and get rid of this warning!
1. Which kind of parameter should I use?
There are 3 kinds:
Configuration parameters
System properties
Environment variables.
I don't want an environment or system variable because I don't want this build to depend on anything external. I am going to try Config right now, but then I'm not sure I'm filling it in right.
2. How can I tell this parameter is actually getting used?
The build log, which seems only to have navigable/foldable xml-like levels with their program, did not say the build parameters.
You should use "System properties". Don't worry about the name, that's just how TeamCity calls it. They are regular properties. You can add them in "Edit Configuration Settings > 7. Build Parameters".
For example, you can add the system property as follows:
Name: system.FileAlignment
Type: System property (system.)
Value: 4096
Note that TeamCity will insist on the "system." prefix. It doesn't matter because the MSBuild script will still see it as $(FileAlignment).
The TeamCity documentation defines Build Parameters as "a convenient way of passing generic or environment-specific settings into the build script". Configuration parameters provide a way to override some settings in a build configuration inherited from a template. They are never passed to a build. System and Environment parameters are provided to your build script. Environment variables are actually set on the system (I can't find any documentation for this). System parameters are passed to the script engine.
TeamCity automatically provides System variables to the actual command line (it looks like the Visual Studio runner runs msbuild.exe and not devenv.exe). I guess that TeamCity is constructing a command like
cmd> msbuild.exe my-solution.sln /p:FileAlignment=4096
I tried this on my command line, just to make sure that it should work (I added the /v:diagnostic flag). The diagnostic verbosity makes msbuild print all of it's properties to the console. I verified that FileAlignment=4096 was in there.
That /FileAlignment property appears to be a special property that's automatically in any .csproj file. So you should be good to go. You can check the actual parameters that were passed to the build by clicking on any build and viewing the 'Build Parameters' tab. There's a section that shows the "Actual Parameters on Agent".
This was solved. To clarify, Anthony told how to solve the problem in the commandline using MSBuild. It can also be solved on the commandline using devenv, per a ticket with Microsoft, the syntax is:
devenv ..\..\mysolution.sln /Rebuild /Property:Config=Release;Platform=AnyCPU;Filealignment=512
What I wanted, however, was to get Teamcity's "Visual Studio Build" to accept the parameter. This was achieved as follows. In the box for Command line parameters, I entered:
/Property:FileAlignment=filealignment v:diag
Then the output tab for Build Parameters shows:
User Defined Parameters
Name Value passed to build
system.filealignment 512
system.verbosity diagnostic
(This is -754 chars for a comment so must be typed as a post)
hi Anthony, Thank you for replying!
Yes, msbuild on the commandline works fine for me as well and project files may store FileAlignment properties. In our case, upon discussion with Microsoft, it appears necessary that I specify the solution-wide aka build-wide alignment, ie in the command arguments, in addition to fixing the projects (which I have already done).
No parameter that I specify on the GUI item ( /Build Step / Command line parameters/ ) will appear on the tab /Build Parameters/. Of course some will not compile at all.
Also I have even more weird behavior where using
/verbosity:diagnostic
vs
/verbosity:minimal
causes a longer build log for the minimal! It appears diagnostic is hiding the details inside of a special task, which is part of Teamcity and not me;
[16:24:05]: Overriding target "SatelliteDllsProjectOutputGroup" in project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" with target "SatelliteDllsProjectOutputGroup" from project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets".
I am struggling with this because the Teamcity-generated build output log is so nice to have as a TreeView. That works with the SLN build but using any bat file cannot produce log file with the pretty (xml, presumably) tree-format.
If you have further ideas I will love to hear them, and thank you for your edits! :)
We have CODE_ANALYSIS defined in our C# components so that FxCop analyzes them when we build them on our development boxes. I would like to have FxCop turned off when it runs through our build system. The build system is obviously using the msbuild.exe command line command. Is there a way to modify the conditional compilation symbols from this executable? If not, does anyone know any other possible solutions to my problem (other than turning it off manually)?
Thanks.
The CODE_ANALYSIS compilation symbol controls whether the SuppressMessageAttribute instances included in the code are copied into the compiled assembly. It does not control whether FxCop runs. If you want to override a project-level MSBuild property like RunCodeAnalysis (which is the beastie that controls whether FxCop runs under MSBuild), you should be able to use the MSBuild.exe /property command line switch. e.g.:
msbuild.exe <...> /property:RunCodeAnalysis=true
Why do you need to turn them off? The best way to set up the project is to define CODE_ANALYSIS for debug configurations only. The release version will not have this value set. That way, when you build production installs, they will not have any references to FxCop.