I am seeing a weird issue on opening the newly merged fpr file. It gives me an error like "this project contains 4.5 style analysis value. This wizard will migrate the project to 6.3 "
Kindly help.
I am able to open the file previous to merge.
Thanks!!
4.5 style analysis values were before SCA 5.0 was released around 2008 (and before the defunct "Fortify 360" product was created, which set the product version back to 1.0.
Unless one of the files you are merging is from the <2008 version of SCA, this error message is unexpected. Contact Fortify Technical Support.
Related
We're using SonarQube 5.6.6 (LTS) with SonarC# plugin version 6.5.0.3766 and TFS 2017 update 2 (SonarQube plugin v. 3.0.2).
We're repeatedly seeing, that issues that were previously marked as resolved (Won't fix) get reopened. My question is: Why does SonarQube behave in this way?
This issue is also mentioned in a number of different posts(1,2,3) on StackOverflow but with no root cause or resolution. Link 3 also states that this is an issue using SonarQube 6.2.
I'm curious as to whether this is due to a misconfiguration on our part or an integrated part of SonarQube?
Our SonarQube server is running on a Win 2012 R2 server with a MS SQL backend if thats relevant?
Furthermore, we're using TFVC for versioning and get blame through the SCM plugin. If an issues has been marked as resolved (won't fix), I've noticed that it appears to be as opened as a new issue (i.e. no history available).
Example: A colleague marked an issue as resolved (won't fix) in a file which was last modified in TFVC back in november 2015. However, this morning the issue was marked as open and assigned to the developer who originally checked in the code There is no history in SonarQube of the issue having previously been in a resolved state. It appears as if it's a new issue in a new file instead of being a known issue which has already been resolved?
To avoid weird issues related to compiling our C# solution we always clean our workspace completely prior to our build. I don't know if that has something to say? Our builds are also executed on different build machines so I don't know if that will make SonarQube think that we're indeed always analyzing new files?
Could the use of different build machines and/or build definitions for the same SonarQube project result in this behavior?
I've also seen from the logs and reports, that SonarQube appears to analyze the ENTIRE solution and not only the changed files. This makes our analysis very time consuming and not at all suitable in a fast feedback loop. I suspect the long analysis period and the issues reopening is related.
Analysis of a projekt with approx 280 KLOC takes approx. 8-10 min. as a background task on the server. That's on subsequent analysis (i.e. not the first run).
Is this related to the above mentioned problem of issues getting reopened by the server?
Strangely enough, leak periods appear to work correctly, i.e. we correctly identify issues within the right leak period. I've not verified this in detail yet, but it's definitely not ALL old issues that get reported as open within the leak period. We only see old issues reappear, if the file that contains them has been modified - this activates all the other issues (from a previous version or leak period) within that file.
I've not specified any additional cmdline parameters for the SonarQube scanner during builds apart from the TFVC SCM plugin and path for coverage data.
We're using the VSTEST task v. 2 as otherwise it's not possible to collect code coverage in SonarQube when using TFS 2017 update 2 and VS 2017.
Please advise of any further data that I should supply to help this further.
Thank you for your help!
We have an ASP.Net MVC Core project solution in TFS.
And there is an error icon at the top of the solution explorer that says "Package restore failed".
And if I open up the project.json I see the red sqigglies:
"The dependency ... could not be resolved" for several dependencies.
The developer who created this error has since fixed it. And all the other developers on the team get latest and the error goes away.
But it won't go away for me.
I get latest and the error icon at the top of the solution explorer and the errors within the project.json are still there.
I blew away the folder, got latest from Team Explorer, and the errors are still there while gone for the other errors.
Anyone know why this is happening?
I'm stumped. I don't understand what is happening.
First, you could try to do a force update for the specific error fixed changeset.
To force a update, use the "Get Specific Version" command with the
"Overwrite all... " option checked.
You could also clear TFS and VS cache, delete old workspace(back up changes first), create a new one, then do a fresh getting latest files from TFS source control. Which should do the trick.
If the issue still exist, you will have to check your local environment if you are missing some thing. Do a simply compare of the environment with other developers on the team.
It turns out this was a combination of the way .Net Core stores nugget packages and of being in a government environment.
We log into our computer with one account that does not have admin priveledges and this is the one I develop with in order to connect to TFS. But there seems to be a lock on the users folder for this account. So when I start up the solution and project.json tries to resolve all the packages, if one is missing it can't download it and put it in that folder. I then have to start Visual Studio as an Admin and open the project. Then the missing package is downloaded to the nugget package folder under my Admin user's folder. Then I read the resolution failure output at the top of the solution explorer next the the red circle with the X in it to see which package is missing and copy it over. It may be more than one so you have to close VS open back up as the non admin account and look for the next one that fails.
I updated to Visual Studio 2015 when it was released last week. Resharper suggested that I might like to update the following string using string.Format:
string filePath = HttpContext.Server.MapPath(string.Format("~/App_Data/{0}.xlsx", Guid.NewGuid()));
To use string interpolation:
string filePath = HttpContext.Server.MapPath($"~/App_Data/{Guid.NewGuid()}.xlsx");
I did this, and all is well.
However I've broken the build on TFS:
Controllers\MyController.cs (224):
Unexpected character '$'
So it seems like the new features in C# 6 can't be compiled by our older, non-updated version of TFS.
The project is still targeted at using the Framework 4.5 however, I have not targeted 4.6. I (wrongly) assumed that still targeting the old framework would mean it could be built by other team members still using VS2013 along with our TFS build server.
So it looks like our TFS needs an update of... something.
What do I need to install on the TFS server to have it compile this new syntax? The latest version of the .NET Framework or something else?
Install .NET Framework 4.6 and Build Tools 2015 on your build server.
Then override the ToolsVersion (/tv:14.0) in MSBuild arguments.
Unfortunately, there doesn't appear to be an easy way to get older versions of TFS working with C# 6.0 without installing VS2015 on the TFS build server. If you can do that, I would suggest that. If, for whatever reason, you cannot, then the following worked for me:
I followed the instructions of the other answer, but that alone didn't work. I also had to edit the default TFS build process template (which in my case is found in $//BuildProcessTemplates) and change the ToolPath properties of the "Run MSBuild for Project" nodes to the location of MSBuild 14.0 (which usually is C:\Program Files (x86)\MSBuild\14.0\Bin).
You will then need to update your build definitions to use the new build template (if you had copy/edited a new one vs editing the original one).
At this point, you should be able to build C# 6 projects with TFS, but if you're trying to do web deployment/packaging as well, then there are still a few more steps.
On the build server, at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0, there should be a Typescript folder and nothing else. On your local machine with VS2015, go to the same path. There should be a Web and WebApplications folder. Copy those over to the server's folder. You should now be able to package/deploy web projects as well.
Please check to see if "Run MSBuild for Project" exists more than once within your TFS Build process template. In my case it existed twice and took me awhile to figure out why the change for ToolPath was not taking the desired effect.
I've been tasked with setting up a new Team Foundation/Build server at my company, with which we'll be starting a new project. Nobody here currently has experience with TFS, so I'm learning all of this on my own. Everything is working so far; The server's been set up, the Repository and Team Project has been created, the Build Server has been created, and I've created a simple hello world application to verify the source control and Continuous Integration builds (on the build server) run properly.
However, I'm having a problem setting up the automatic versioning. I've installed the TfsVersioning project, and it's working fine; I'm able to define a format for my assembly versions. I haven't yet decided what format I'll use; probably something like Major.Minor.Changeset.Revision (I'm aware of the potential problem regarding using the changeset number in the assembly version, so I may decide to switch to Major.Minor.Julian.Revision before we begin development).
The problem:
I don't want assemblies to have new file versions if their source code has NOT changed since the last build. With a continuous Integration build this isn't a problem, as the build server will only grab the source files that have changed, causing an incremental build which produces only updated modules; the existing unchanged modules won't be built, so their version will remain unchanged.
If I set up a nightly build, I'll want to clean the workspace and perform a Build-All. However, this means that ALL assemblies will have new version (assuming the Assembly File Version includes the build number).
A solution?
This has prompted me to consider using the latest changeset number in the Assembly File Version. This way, if nothing has been committed between two successive Build-Alls, the versions won't be incremented. However, this would mean that a change and commit to a single file would force a version increment on ALL assemblies.
I'm looking for one of two things:
A way to only increment Assembly Version Numbers if their source/dependencies have changed since the last build. Successive Build-Alls should not cause changes in version numbers.
OR
A way for testers and non-developers to be able to tell version W.X.Y.Z and version W.X.Y.Z+1 of assembly 'Foo' are identical, even though they have differing file versions.
I've probably read about 20 articles on the subject, and nobody (except this guy) seem to address the issue. If what I'm asking for isn't common practice in the Team Foundation ALM, how do I address the second bullet point above?
Thanks for your time!
This is something I did in the past. The solution has two critical points:
You must use an incremental build, i.e. Clean Workspace = None
The change to AssemblyInfo.cs must be computed at each project
This latter is the most complex and I will just draft the solution here.
In the custom MSBuild properties use CustomAfterMicrosoftCommonTargets to inject an hook in normal Visual Studio compile
/property:CustomAfterMicrosoftCommonTargets=custom.proj
Also forward a value for the version
/property:BuildNumber=1.2.3.4
In custom.proj redefine the target BeforeCompile to something similar
<Target Name="BeforeCompile"
Inputs="$(MSBuildAllProjects);
#(Compile);
#(_CoreCompileResourceInputs);
$(ApplicationIcon);
$(AssemblyOriginatorKeyFile);
#(ReferencePath);
#(CompiledLicenseFile);
#(EmbeddedDocumentation);
$(Win32Resource);
$(Win32Manifest);
#(CustomAdditionalCompileInputs)"
Outputs="#(DocFileItem);
#(IntermediateAssembly);
#(_DebugSymbolsIntermediatePath);
$(NonExistentFile);
#(CustomAdditionalCompileOutputs)"
Condition="'$(BuildNumber)'!=''">
<Message Text="*TRACE* BuildNumber: $(BuildNumber)"/>
<MyTasksThatReplaceAssemblyVersion
BuildNumber="$(BuildNumber)"
File="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"/>
</Target>
You need to have a task for replacing the AssemblyFileVersion in the AssemblyInfo.cs source. MSBuild Extension Pack has an AssemblyInfo task for this purpose.
I posted the full details at my blog here, here and here.
We used to use SourceSafe, and one thing I liked about it was that when you checked out a file, it automatically got you its latest version.
Now we work with Team System 2005, and it doesn't work that way - you have to "get latest version" before you start working on a file that you've checked out.
Is there a way to configure Team System (2005) to automatically get the latest version when checking out a file?
There's a Visual Studio Add-in for this that someone wrote:
http://blogs.microsoft.co.il/blogs/srlteam/archive/2007/03/24/TFS-GetLatest-version-on-check_2D00_out-Add_2D00_In.aspx
Are you sure you want that?
It means that when you check out a file, it will be out of sync with the rest of your files. Your project may not build or function properly until you update all files.
#Vaibhav: Thanks a lot!
#Jay Bazuzi: I understand what you're saying, but for me it's very important that if a developer is working on a file, it be the lastest version of that file. Otherwise the check in introduces a lot of problems. If for some reason, as a result of the getting latest version, the project doesn't compile, then by all means get the latest version of the whole project. For the way our team works - often check-ins - this is good. If you made changes you want to keep - shelve them.