I'm trying to figure out why code analysis would run and detect errors on our build server, but I don't see the same errors when building locally. Here is one example of code that's failing (because of our STBi acronym):
string message = string.Format(CultureInfo.CurrentCulture,
"Unit STBi [{0}] blah... ",
unitStbiParameter.Stbi);
The build fails on our TFS build server with errors like this:
CA2204 : Microsoft.Naming :
Correct the spelling of the unrecognized token 'STBi' in the literal
'"Unit STBi ["'.
The problem is that I don't know why I'm not seeing these CA errors when I build the solution on my laptop. This is in the project's properties:
And the build definition has this:
Why would errors show from a build on the build machine but not my laptop? It's almost like the build server is using a different CA rule set. Is that possible?
Side note: I tried adding STBi to the CustomDictionary.xml (below), but that still didn't help. But that's a separate issue.
<!-- This is here because it's a workaround for a bug: http://connect.microsoft.com/VisualStudio/feedback/details/521030/ -->
<DiscreteExceptions>
<Term>STBi</Term>
</DiscreteExceptions>
You probably need to specify the CodeAnalysisCulture MSBuild property in your project(s) (see http://blogs.msdn.com/b/codeanalysis/archive/2007/08/12/new-for-visual-studio-2008-spelling-rules.aspx for an example). Without this set, spelling rules will use the Windows UI culture information for the account under which the analysis is running, which is presumably different for your account and the build account.
Are you building debug locally and release on the Build Server? If so, check that the CA settings are the same for debug and release, and that your dictionary is checked in and the same on the build server.
My team use CA enabled on debug builds and CA is disabled on the build server. The code analysis check-in policy ensures that CA has been run on all code in source control, so is there any point in slowing down your server builds with repeated code analysis passes?
Related
I am trying to integrate Fitness with Visual Studio 2022. Have .NET 6.0 installed. Following the instructions given in this link. However, every time I run the Test it throws the error
Could not complete testing: fitnesse.slim.SlimError: Error SLiM server died before Header Message could be read. Unable to start test system 'slim': fitnesse.slim.SlimError: Error SLiM server died before Header Message could be read.
Looks like I am missing something very basic about Slim. Please let me know the resolution for this.
I was able to resolve this. The Target Framework RunnerW was pointing to was incorrect. It was pointing to Dotnet4.8. I modified this. But, and included into the fitsharp solution. Then, building solution from Visual Studio kept failing. Identified that this needed updating the Nuget package. Updating kept skipping every time stating the package was already installed. Was unable to build because of these reasons. Was finally able to have breakthrough when I built the solution from cli. Running the Test after this was successful.
I have a C# WPF application. It uses a small commercial framework (https://www.inosoft.com/en/product/product-features/).
I'm building this application both locally and via a buildserver (Azure pipelines). I use a marketplace task to change the assemblyinfo.cs before building: https://marketplace.visualstudio.com/items?itemName=bleddynrichards.Assembly-Info-Task
The build server executes the following tasks:
NuGet restore
Inject/Edit assemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion with the right version info
Build
Now when I run this application, it starts up and runs for a while.
Quickly after starting I hook the VS debugger into the process.
Then all of the sudden the application crashes:
This is weird, because when I build locally, this runtime error does not occur.
Note that i set all properties to the same values for testing:
AssemblyVersion: 1.2.3.4
AssemblyFileVersion: 5.6.7.8
AssemblyInformationalVersion: 9.10.11.12
I then use Telerik justAssembly to compare the build output from my local build and the buildserver:
As we can see the local output (on the left) does not have a version added to the Application.LoadComponent(..) whilst the build server output (on the right) does.
public void InitializeComponent()
{
if (!this._contentLoaded)
{
this._contentLoaded = true;
Application.LoadComponent(this, new Uri("/HmiMetis;component/views/app.xaml", UriKind.Relative));
}
}
This means that this is the root cause of the runtime exception.
I find it weird that the build process on my local machine differs from the build server output. Both (should) use visual studio 2017 to build. Why does the buildserver add the version to the uri of loadComponent and my local machine does not?
Anyways, I need this exception gone.
Therefore I think the easiest way would be to force the buildserver to not add the version information under any circumstances. Is this possible and how?
Edit:
I Found a relating issue report that may have something to do with this:
https://github.com/dotnet/core/issues/3189
On the sonarqube website the new C# plugin documentation states 'native support for fxcop'
However there is no explanation how to get fxcop running. It does not work out of the box.
What i did so far and works:
installed Sonarqube 5.1
using msbuild.sonarqube.runner
The sonarqube C#,xml,js analysis al work like a charm.
What does not work is using fxcop rules.When i enable 1 rule i get the runner to give the following exception:
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLaunc
her.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53) Caused by: java.lang.IllegalArgumentException: The property "sonar.cs.fxcop.a
ssembly" must be set and the project must have been built to execute
FxCop ru les. This property can be automatically set by the Analysis
Bootstrapper for Visual Studio Projects plugin, see:
http://docs.codehaus.org/x/TAA1Dg.If you wish to skip the analysis of
not built projects, set the property "sonar.visu
alstudio.skipIfNotBuilt".
What i tried so far:
followed the provided docs.codehaus.org/x/TAA1Dg link but this is a dead link. It states "All Codehaus services have been terminated".
added sonar.cs.fxcop.assembly property to the sonarqube.analysis.xml but this does not change anything to the error.
added sonar.cs.fxcop.installdirectory property to the sonarqube.analysis.xml file. This changes the error messages to:
Caused by: java.lang.IllegalArgumentException: Cannot find the
assembly "C:\p
rojects\mercurial\ccvs.sonarqube\bin\sonar-runner\bin\"FxCopCmd.exe""
provided by the property "sonar.cs.fxcop.assembly".
But i'm unable to the the fxcop installation copied to this folder. I also failed to influence the path to be redirected to my fxcop installation which comes with vs2013(C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe)
Another thing is that the sonar-project.properties file next to the .sln file is not picked up by this new msbuild sonar runner thats why i edit the xml file.
In short a step-by-step on the guide how to get fxcop working together with sonarqube 5.1 and the msbuild sonarrunner on the site of sonarqube would be appreciated.
I thinks you should read
http://www.sonarqube.org/easy-analysis-of-visual-studio-solutions-with-the-sonarqube-scanner-for-msbuild/
and
http://docs.sonarqube.org/display/PLUG/C%23+Plugin .
Pay attention to the fact that you should run the commands from a "Developer Command Prompt for Visual Studio 2013 or higher" (http://docs.sonarqube.org/display/SONAR/Analyzing+with+SonarQube+Scanner+for+MSBuild).
Neither DOS Command Prompt nor Windows PowerShell work because they don't set the proper variables.
The FxCop native support doesn't mean that it comes with MSBuild SonarQube Runner, but you have to install Visual Studio >= 2013 (as I think you understood from your message).
Moreover, I found that not only sonar-project.properties has been deprecated, but you have to remove it to avoid strange behaviors.
I have setup my TeamCity to build using MsBuild a project that NuGet packages.
During the build, the following command to install packages is issued, but fails:
..\nuget.exe install "C:\TeamCity\buildAgent\work\811b6866c8757c46\Service\packages.config" -source "https://nuget.org/api/v2/" -RequireConsent -solutionDir "..\ "
Error:
Unable to connect to the remote server
with exit code 1.
Interesting to note is that when I run this exact same command on the cmd prompt (inside the same path), it succeeds without any errors.
This is what I have done so far:
Add a new Build Parameter under environment variables in TeamCity: env.EnableNuGetPackageRestore and set it to 'true'
Add a specific path to the package sources (https://nuget.org/api/v2/) inside the ..nuget\nuget.targets file (as described here)
To provide the additinal paths ways to supply a path:
Modified the nuget.config file inside the .nuget folder (..nuget\nuget.config)
Modified the nuget.config for the SYSTEM account that the build runner is executing under (C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\nuget.Config) (as described here)
What I was thinking is that this has something to do with a roaming profile of the System user (that the build agents runs with) because it all works when build agent runs with my account. But the nuget.config is the same for both profiles, and I'm out of ideas. Maybe the System user doesn't have access to the Internet on WinServer2012R2? Maybe it needs additional permissions? Which ones?
Do you have any ideas of what to try?
The error turned out to be the setting for the ISA server we have on our network (the TMG client). By default this isn't set up for new (local) users and therefore the SYSTEM account didn't have access to the web.
I've set this up for a new local user (non-domain, with password that doesn't expire), added it to Administrators group and now it works just fine.
From C# code I'm trying to retrieve all the namespaces from powershell... (Later more complex things, like creating namespaces)
PowerShell ps = PowerShell.Create();
ps.AddCommand("Import-Module").AddArgument("ServiceBus").Invoke();
var result = ps.AddCommand("Get-SBNamespace").Invoke();
Above code gives the following exception:
The 'Get-SBNamespace' command was found in the module 'ServiceBus',
but the module could not be loaded. For more information, run
'Import-Module ServiceBus'.
Does anyone know how to solve this error?
CURRENT STATUS: after some debugging I've found that no modules are loaded by default in the PowerShell object. Using the code:
InitialSessionState iss = InitialSessionState.CreateDefault();
iss.ImportPSModule(new string[]{#"serviceBus"});
PowerShell ps = PowerShell.Create(iss);
doesn't work to load the service bus module. Also the code:
ps.AddCommand("Import-Module").AddParameter("-Name", "serviceBus").Invoke();
doesn't work to import the service bus module. Running Visual Studio in administrator mode also doesn't make a difference
Thanks in advance
You didn't say which version of Visual Studio you're using. If it's VS 2012, when you tried the x64 platform target did you make sure that "Prefer 32-bit" was not checked? Even if it was not checked try checking it, saving the project configuration, clearing it and saving again - this worked for me on another project.
UPDATE
It's been suggested elsewhere that there's a bug in VS2012 that shows "Prefer 32-bit" as greyed-out and unchecked when it's actually active. I'm running Update 2 and I don't see that. But it sounds like you might be. I suggest you edit the .csproj file directly.
Whilst "Platform Target" is set at "Any CPU", in Solution Explorer, right-click on the Project name (or, with go to the PROJECT menu) and select "Unload Project". Project files will close and Solution Explorer will display project name (unavailable) > The project file was unloaded:
Right-click on the Project name again and select "Edit project name.csproj". The file is XML and mostly comprises PropertyGroup and ItemGroup elements. In a console project, the first PropertyGroup usually contains a Platform element which should read AnyCPU if you followed my instructions above. The next two PropertyGroups are normally for Debug and Release configurations. If you've added another configuration, it will have its own PropertyGroup. In each of these, look for an element which reads:
<Prefer32Bit>true</Prefer32Bit>
What you should have is an element which reads:
<Prefer32Bit>false</Prefer32Bit>
Either change it or insert it (in each configuration ProjectGroup), save the file and close it. Back in Solution Explorer, right-click the project and select "Reload Project". Let me know if that solves it. You can confirm your PowerShell is now running 64-bit by get the result of
[System.IntPtr]::Size
e.g.
ps.AddScript("[System.IntPtr]::Size");
which will be 4 in an x86 process and 8 in an x64 process.
Which my project set up like this, I was able to load ServiceBus using:
ps.AddCommand("Import-Module").AddArgument("ServiceBus");
Hopefully, you will, too.
I don't have ServiceBus installed so I can't verify exactly what you've tried but
ps.AddCommand("Import-Module").AddArgument("ActiveDirectory").Invoke();
worked for me, so your original syntax looks good.
Just to test for failure, I tried:
ps.AddCommand("Import-Module").AddArgument("CheeseDirectory");
ps.Commands.Commands[0].MergeMyResults(PipelineResultTypes.Error, PipelineResultTypes.Output);
var importResult = ps.Invoke();
foreach (PSObject result in importResult)
{
Console.WriteLine(result);
}
and got
The specified module 'CheeseDirectory' was not loaded because no valid
module file was found in any module directory.
Have you tried similar?
Do you take care of your Assembly target in your C# program (x86 versus X64). The module may exist in one target, not in the other. PowerShell exists in both.
Seems you're trying to import some modules and execute the cmdlet or function inside the module, right?
So I think you could try the following code:
PowerShell ps = PowerShell.Create();
Assembly ass = Assembly.LoadFile(#"yourServiceBus.dll");
ps.AddCommand("Import-Module").AddParameter("Assembly", ass).Invoke();
var result = ps.AddCommand("Get-SBNamespace").Invoke();
Hope this could help.