Running FxCop using SonarQube results in an assembly resolve issue as I have an assembly binding redirect which is not recognized by FxCop.
Is there a setting in SonarQube to call FxCopCmd with option /assemblyCompareMode:StrongNameIgnoringVersion to solve this problem? I could not find anything in the documentation.
The current version of the SonarQube runner plugin for FxCop does not seem to support either this command line parameter or a setting for specifying ad-hoc parameters. If you don't feel like adding this support yourself, one workaround would be to change your fxcopcmd.exe.config file to add an appropriate AssemblyReferenceResolveMode setting. e.g.:
<add key="AssemblyReferenceResolveMode" value="StrongNameIgnoringVersion" />
Related
I want to build my solution file in azure devops. I have added this to build pipeline, I see this step doesn't succeed. It tells " MSBUILD : error MSB1008: Only one project can be specified." I suspect I am making some mistake in specifyning
msbuild args
msbuild $(Build.SourcesDirectory)\ansysfnonet\ansysfnonet.vs2017.sln /t:$(Build.SourcesDirectory)\ansysfnonet\ansysfnonet.csproj:Rebuild;
I tried specify only proj file as msbuild arg it didn't work for me
I tried without specifying msbuild it throws me whole lot of errors.
Someone please help me , why I am failing in this step and how to solve this error.
Thanks
You don't need to specify an msbuild command line in the MSBuild Arguments field. You need to specify any additional MSBuild parameters beyond the defaults.
Clear that field. That should fix the problem you're encountering.
I have a problem with the standard MSBuild.exe used on our Team Build server, the standard version used is in
"C:\Windows\Microsoft.NET\Framework\v4.0.30319", version 4.0.30319.18408 or
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" respectively (same version).
Using this version leads to Fake dlls not being generated in the same way as on our local development machines (i.e. some fake methods are missing on the server), resulting in broken builds (unit tests) on the TFS.
I updated the build definition template to use the MSBuild version located under "C:\Program Files (x86)\MSBuild\12.0\Bin" as it is more recent (version 12.0.30723.0), however, this results in an error MSB1025, System.Threading.Tasks.Dataflow, Version=4.5.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a not found.
Update
Further investigation - manually adding the System.Threading.Tasks.Dataflow.dll with the correct version number to the MSBuild directory results in a broken build with
Unsupported ToolsVersion 12.0
Manually setting the ToolVersion in the Microsoft.TeamFoundation.Build.Workflow.Acitvities.MSBuild element to "4.0" results in a broken build with
Cannot set unknown member "Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild.ToolVersion"
So... no real improvement.
Any ideas how to fix this?
Fakes is sensitive to the Visual Studio version. Try passing /p:VisualStudioVersion=12.0 to MSBuild arguments. Also avoid handling System.* assemblies manually.
I am using cruisecontrol.net to build and deploy as part of the continuous integration. During the build process, it shows many warnings as shown below:
Read-only property "CCNetLabel" cannot be overwritten.
Log\ILogRecord.cs(10,18): warning CS0108: 'My.Interface.Log.ILogRecord.Level' hides inherited member 'My.Interface.Log.ILogTuple.Level'. Use the new keyword if hiding was intended. [d:\Build\mysite\abc\Technology.Interface\Teach.Interface.csproj]
These are benign warnings with no bearing on the build process. Is there a way to suppress them?
Thanks
Try these parameters in your msbuild task in your ccnet.config file. It passes these to the msbuild executable.
<buildArgs>/consoleloggerparameters:ErrorsOnly /verbosity:minimal</buildArgs>
They are documented in the msbuild command line reference
https://msdn.microsoft.com/en-us/library/ms164311.aspx
I'm getting the following error from a build I'm running through TeamCity on my development machine:
[ResolveServiceConfiguration] WATMessage
[16:02:05][WATMessage] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\1.7\Microsoft.WindowsAzure.targets(354, 5): No default service configuration "ServiceConfiguration.cscfg" could be found in the project.
[16:02:05][Xxx.Azure.Production\Xxx.Azure.Production.ccproj] Project Xxx.Azure.Production\Xxx.Azure.Production.ccproj failed.
The same solution builds okay in VS.NET.
I think what I need to do is set the TargetProfile for each of the Azure projects (there's more than one complaining) to override the default of Cloud but I can't find out where to do this.
So how do I set the Target Profile for an Azure project?
Have you tried setting the target profile at command line?
/p:TargetProfile=MyProfile
Given an Azure service configuration file named "ServiceConfiguration.Production.cscfg":
In your TeamCity project build configuration, go to Build Parameters (step 7)
Add a system property with the name "system.TargetProfile" and a value of "Production"
This pattern applies for any named configuration in the format ServiceConfiguration.[your profile].cscfg.
To work around this problem I have created ServiceConfiguration.Cloud.cscfg for each Azure project using the .cscfg that was being set in the definition.
In my case, I renamed the ServiceConfiguration.Cloud.csfg file, and since the build agent will first look for that file because the default TargetProfile is "Cloud", I had to re-create the ServiceConfiguration.Cloud.csfg file in the same location, then went into the .ccproj file and added this line under the <ItemGroup> node:
<ServiceConfiguration Include="ServiceConfiguration.Cloud.csfg" />
Then I rebuilt and the problem was solved.
I have the msbuild plugin installed on my Hudson server, and it's attempting to execute the command, but for some reason the path I'm setting in my configuration is not being used when the msbuild task gets fired.
I have the following set in the configuration of hudson's msbuild plugin:
Path To msbuild.exe C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
I left the name property blank.
When I do a build it outputs this:
Executing command: cmd.exe /C msbuild.exe /p:Configuration=Release ...
Which I know is wrong because all the other examples show the [msbuild.exe] part fully qualified.
I've been searching everywhere trying to figure out why this isn't getting set properly and I've hit a brick wall.
Does anyone know how to fix this?
This works for me:
in the main hudson configuration I
set the name to local-msbuild and
the path to msbuild to
C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
select the local-msbuild as the MsBuild Versionin each project, instead of (default)
Of course, this begs the question why there IS a '(Default)' option that never works.
One hacky way around this is to set the name of your msbuild to (Default) in the main hudson configuration. Then in your project configurations, you have two (Default) options, but they both work... so you can leave it set to the default (Default) on new projects and it still works.
I had this problem.
I fixed it by going to the Project Configuration Page to the Build Section.
There is an option to set "MsBuild Version" with a dropdown box with 2 options: 1) Default; 2)MSBuild.
Mine was set to Default. When I changed it to MSBuild the path set on the System Configuration page was used.