Is there a way to force MSBuild to treat a certain warning as an error?
When running the Publish target for a ccproj file to make a cspkg for deployment to Azure, this error is thrown:
Project.Name : warning WAT150: The project 'Project.Name' is
dependent on the following assembly:
C:\Windows\assembly\GAC_64\DllName\2.10.0.0__Guid\DllName.dll. This
assembly is not in the package. To make sure that the role starts, add
this assembly as a reference to the project and set the Copy Local
property to true.
[C:\bld\66\797\Sources\Applications\cloud\Project.Name.ccproj]
This is a warning that probably means a role won't start when deployed... I'd like to make WAT150 an error. Is there a way to make a specific, single warning or list of warnings an error?
In MSBuild you can use the /warnaserror command line switch
/warnaserror[:code[;code2]]
List of warning codes to treats as errors. Use a semicolon
or a comma to separate multiple warning codes. To treat all
warnings as errors use the switch with no values.
(Short form: /err[:c;[c2]])
Example:
/warnaserror:MSB4130
When a warning is treated as an error the target will
continue to execute as if it was a warning but the overall
build will fail.
This is equivalent to setting the <WarningsAsErrors> property in the project file (docs).
For completeness, the C# compiler also has the -warnaserror command line option (docs).
in the msbuild commandline options you have this:
warningsAsErrors
Specifies a list of warnings to treat as errors. This parameter is equivalent to the /warnaserror compiler switch.
doc link : http://msdn.microsoft.com/en-us/library/vstudio/bb629394(v=vs.100).aspx
Related
I found // +build OMIT in this page https://blog.golang.org/context/server/server.go
I know what a build constraint is.
OMIT isn't
a GOOS or GOARCH value
a compiler name
cgo
a term for each Go major release as go1.12
any additional tags given by the -tags flag
Does it literally mean "omit something here" as // +build ignore keeps a file from being considered for the build ?
The source file is ignored when the the build tag OMIT is not specified. It works the same way as ignore. The OMIT and ignore tags have no special meaning to the build tools.
The file is included in the blog post using the present package .code command. The .code command ignores source file lines ending with OMIT.
In summary, two things are going on. The build constraint is used to ignore the file. The tag OMIT is used instead of the more common ignore so that the build constraint does not appear in the blog post.
The program is run using go run server.go. The go run command ignores build constraints.
I'm trying to use SonarScanner with SonarCFamily plugin on my C codebase on ubuntu. I see that the scanner is able to only detect "code smells - duplicate blocks of code" in my codebase and no other forms of bugs/vulnerabilities. I intentionally added a memory leak in the code and SonarQube couldn't detect it while open source SA tool Cppcheck was able to. Am I missing some setting in the sonar-project.properties file ? My sonar.properties file is as follows. Are there any settings needed in the server/SonarCFamily plugin for the tool to detect other forms of SA errors ?
# must be unique in a given SonarQube instance
sonar.projectKey=c-sa-test
# this is the name and version displayed in the SonarQube UI. Was mandatory prior to SonarQube 6.1.
sonar.projectName=c-sa-test
sonar.projectVersion=1.0
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# This property is optional if sonar.modules is set.
sonar.sources=src
# Encoding of the source code. Default is default system encoding
sonar.sourceEncoding=UTF-8
sonar.host.url=http://localhost:9000
sonar.cfamily.build-wrapper-output=bw_output
sonar.c.file.suffixes=.c,.h
sonar.cpp.file.suffixes=.cc,.cpp,.cxx,.c++,.hh,.hpp,.hxx,.h++,.ipp
Found the root cause - Was missing providing some elements of the project build process as input to the build wrapper. Once those were added, SonarQ provided a detailed report.
I had the exact same problem where SonarCFamily was only reporting code duplications. It was due to an incorrect build process as input to the build wrapper. In my case, I was using SonarScanner.MSBuild and on my build-wrapper line, I didn't have the Configuration and Platform specified, so my projects were not getting built or scanned. The final working lines were:
SonarScanner.MSBuild.exe begin /k:"your key" /d:sonar.cfamily.build-wrapper-output=”bw_output”
build-wrapper-win-x86-64.exe --out-dir bw_output MSBuild.exe your_solution.sln /p:Configuration=Release /p:Platform=x64
SonarScanner.MSBuild.exe end
We have our own GCC based compiler. We use eclipse in order to develop .c files using our compiler – after hitting the build button eclipse manages to run our ‘make’ file and the build operation succeeds.
We’re trying to configure the eclipse project such that it will use this compiler in order to show the compilation errors as red underline marks during the code-writing stage.
In order to do so, we add the following configurations:
Project properties > C/C++ Build>Tool chain editor > current toolchain: “Cross GCC”, current builder: “CDT internal builder”
Project properties > C/C++ Build>Settings>Tool Settings>Cross Settings> - here I set the prefix and the path of my GCC compiler.
Project properties > C/C++ General > Preprocessor include path, Macro etc. > providers > check: “CDT Cross Build Output Parser” and inside check “Allocate console in the console view”.
After doing that we get the following error in the console view:
i486-elf-g++ -E -P -v -dD
C:/Users/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Cannot run program "i486-elf-g++": Launching failed Error: Program
"i486-elf-g++" not found in PATH
It looks like eclipse is trying to compile a file named “spec.C”, in the plugin directory. We tried to look for that file and we only found an auto-generated file called “spec.c” (lower case .c) that is empty.
Our compiler executable name is “i486-elf-gcc”.
What additional steps need to be done?
Note that running the make file using the “build” button completes without errors or warnings.
Thanks
This is not related to the spec.c. It seems that the path of the i486-elf-gcc is not in the PATH variable. You can add the path the PATH-varaible in the "Environment" -tab
I want to run tests in comman line using mstest.exe. Here is the command which I am trying to execute
MSTest.exe /platform:[x64] "/testcontainer:D:\Dev\tas\Tests.dll" /resultsfile:"D:\Dev\TestResults.xml"
But everytime I am getting error.
No Build Uri specified for publish operation.
For switch syntax, type "MSTest /help"
I am not using any teamFoundation server. How do I run this?
The /platform command line option is actually related to the publishing, not test execution (as described at http://msdn.microsoft.com/en-us/library/ms182489(v=vs.100).aspx). When you specify at least one publishing option, MSTest validates that the minimum required set of publishing options have been supplied.
Since you don't really want to publish, simply getting rid of the /platform option should fix the problem.
I have inherited a complex MSBuild script which builds & deploys multiple solutions. When I run the script I see the following error in log:
SGEN: Cannot generate serialization assembly
C:\B\268\Agents\Agents.XmlSerializers.dll
because it already exists. Use /force to force an overwrite of the
existing assembly.
I agree that Agents.XmlSerializers.dll exists. What I can't determine is which task caused it to be created and which one initiated the attempt to re-create it.
I have searched through the files in the build hierarchy for 'SGen' and found nothing. So I presume that SGen is called implicitly by two (or more) of the tasks in the build.
Can anyone point out what might call SGen?
Thanks.
In the Build Output window, look for...
Task "SGen"
Right above that is the actual "sgen.exe" command.
And as Pawell said, you need full details in your build output. Inside of Studio, it's Tools - Options... - Projects and Solutions - Build and Run - MSBuild project build output verbosity: Diagnostic.