Our Build fails due to such error:
The folder 'F:\TFS_Agents\Default_work\58\s\Sources\DotNet\foo\OnlineHelp\Syntax' does not exist...
I checked the original folder OnlineHelp, and there is no folder named Syntax inside. Instead there is an auto-generated file named
Syntax,_functions,_currencies_and_units.html
So i suggested to exclude the whole OnlineHelp folder like this:
exclude filter
But still get the same error. Did i do any mistakes with the filter?
The SonarQube Scanner for MSBuild has a known limitation with files containing commas, see SONARMSBRU-199 .
There's anyhow little value in analysing generated code (quality feedback not actionable by end-user), you're better off excluding projects made of generated code.
Related
I'm still trying to create my first Azure Pipeline CI / CD. My CI part is working fine, my CD is also working except I cannot apply my Web.config file transformations.
Let me first show you what I have then I will ask several questions below. The build with generated artifact. I also copy manually my 3 config files.
Wen I open my WebAPI.zip file here is the path and content:
Here is my pipeline project
And the details of my staging phase:
When I run this full pipeline my config file is never transformed but I get no error. I just get a
2019-05-02T03:27:23.5778958Z ##[warning]Unable to apply transformation
for the given package.
I also have the debug log with full information but it doesn't give me much information for now. I will add it here later.
Questions
Azure Pipeline File Transformation is not working. Why?
Is it because the File Tranform task only look for config file in zip?
Is this system then just ignoring my tranformation file in root of artifact?
So I think my manual copy of config transformation file is obsolete?
How can I then add my transformation file into my zip?
In my csproj I already set all my tranformation files on Build action content, copy always, this is ignored too, is it normal?
EDIT 1
One more important question: Is it possible to simply ask the deployment system to ignore or not deploy my config file. It is not something I want to deploy every time. I like the idea I have to do it manually or from alternative deployment system. With this solution I can have some other issues if I save a version or build variable in my config file. Then is it possible to modify a already deployed file after deployment? I'm looking for workaround here. Example: I read a value in my existing config file then I increment this value by one or simply replace this value with another?
EDIT 2
I'm now able to add the config file to the WebApi.zip package on root and/or in bin folder. I followed the comment of Shayki Abramczyk bu using the xml transform of deploy. Still not working. And the errors messages are so poor. Seriously Microsoft? Is your transformation system even working? I see question similar to mine everywhere.
And now I get
The file is correct, transform works fine from Visual Studio Publish tool. I really think the xml transform tool from Microsoft in Azure is just not working.
EDIT 3
Is it possible to issues from my transformmations come from NLog because of the name and then special rule I apply on it?
So we have a project that is basically nothing but test files and other projects depend on it to run tests. Problem in the past has been that these items are being unpacked in locations outside of the target directory. That means you end up with modified files and new files, none of which are committed. The files are XML and are used to generate other files. What is the Maven standard location for these files? I'm looking here and I don't see anything that jumps out at me as a conventional location. I can wing it, of course, but I'd prefer to use a standard if it exists:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide
I'm considering this location:
${project.build.directory}/generated-test-resources/resources
The standard directory for test resoures like xml files is:
/src/test/resources
The way to include these test-only kind of projects is by using test-jar as described here.
In a SonarQube (v6.4) project I recently excluded a set of files but SonarQube still reports open issues for them.
Browsing the list of code for the folders shows that zero lines of code, but a number of issues exist. These issues can be opened, so they still exist.
How can these issues for files that are now excluded be removed?
Excluding files from coverage calculations is a separate step from excluding them from certain rules. For that, see Ignore Issues on Multiple Criteria, which allows you to say "ignore issues from rule X on file Y".
There have been some questions about this, but none of them solves my problem.
I use SonarQube to do code analysis on one of my projects, which contain a Migrations directory. I would like to exclude all the source files in that directory from the code analysis.
In the projects Configuration->Settings->Exclusions->Files->Source Files Exclusions I added "**/Migrations/.", but in the analysis results I still get issues in code files in that directory.
The directory structure of my project looks like this: \MyProject\Migrations\SourceFile.cs
What am I doing wrong? Am I entering the wildcard in the wrong place, or my wildcard is wrong?
In the logs I can see
13:06:23.460 INFO - Copy-paste detection exclusions:
13:06:23.476 **/Migrations/*.*
but then I can also see
13:06:12.076 INFO - Inspecting <MyProject>\Migrations\SourceFile.cs
That's the correct place to set it up. Please try simply /Migrations/** or /MyProject/Migrations/**. When you go to one of the issues you want to get rid of, you'll see what your "regex" path should start with.
And one more tip: To see result, you have to rebuild the project, run sonar again. And again, until you get it right.
I had to use a different setting.
Instead of Configuration->Settings->Exclusions->Files->Source Files Exclusions I had to use Configuration->Settings->Exclusions->Issues->Ignore Issues on Multiple Criteria.
In this setting, I had to set the RULE KEY PATTERN to *, and I had to set the path wildcard in the FILE PATH PATTERN, **/Migrations/. works perfectly.
We have a C++ project that uses a custom object-relational-mapping system, in which tables are defined by .tbl files. These are then run through a code-generator that creates, for each, a .h and a .cpp file.
I'm trying to get a custom build rule working for this, in Visual Studio 2008 and 2010.
This is what I have, so far:
<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
Name="z_dbbld"
Version="8.00"
>
<Rules>
<CustomBuildRule
Name="z_dbbld"
DisplayName="z_dbbld"
CommandLine="$(SolutionDir)\tools\z_dbbld $(InputName)"
Outputs="$(InputName).cpp"
FileExtensions="*.tbl"
ExecutionDescription="z_dbbld $(InputName)"
>
<Properties>
</Properties>
</CustomBuildRule>
</Rules>
</VisualStudioToolFile>
The problem is the dependencies. When I run a build on a clean checkout, where none of the files exist, I get "Cannot open include file" errors, for .h files that are generated by this rule.
I've tried changing Outputs to "$(InputName).h", and I still get the errors.
Now the thing is that these files are created, when the code generator runs. If I compile again, I don't have the errors, because all of the files were created in the first pass. But it makes doing a clean, automated, build from fresh checkout not work.
Any ideas?
I think you need to specify the Output files in the main part of the build (looking at the very last sentence of http://msdn.microsoft.com/en-us/library/hefydhhy.aspx). Probably the easiest way to do that is to add a reference to the files when they exist and then delete them and see if the codegen step runs like it should.
The answer given by sblom is correct, but it does not explain the reason.
For each build rule (custom or native) the VS build system needs to know the complete list of inputs and outputs so that it can decide what part of the project needs to be built.
Your build rule declares the generated .cpp file as an output, so VS knows about it and will automatically build this file for you. Since you omitted the header file, VS does not know about it, so any source files that include this header will not know where to get it from and fail to build. A work around to get the build to work in this situation is to add the directory where this .h file is located to your include path, and then #includes of this file will work. You are basically enabling VS to know about this file in a different way.
Conversely, if you change your build rule to declare the header file as output, then source files that include it will know where to get this file from, but now VS does not know about your .cpp file so it won't build it. A work around for this case is to explicitly add the generated .cpp file to your project as a source file. Like in the above case, you are using a trick to get the build system to recognize the generated file.
But while the workarounds above will get you going they are not the best solution, since they just compensate for VS not knowing about a file. The best way to address this problem is to declare both the .cpp and the .h files as outputs in your rule, separating them with a semi-colon. This will enable VS to apply the correct behavior to both files.