I installed the ReSharper plugin StyleCop by JetBrains to include StyleCop directly into all of our projects, without the need to have the same settings.stylecop or stylecop.json file in multiple projects (since our guidelines are basically identical for all of our projects).
I ran into an issue regarding StyleCop and after posting an issue on the Github page of the plugin I got told that I should use StyleCop.Analyzers since the plugin has been discontinued.
Now I have the following problem. Do I need to explicitly include a corresponding stylecop.json file within each of our projects to make StyleCop work with the newest features? Or is there another way to tell ReSharper to use a default StyleCop configuration for all of our projects? I know it's not that big of a deal to add a file to a project. But it's a little bit tedious to have the same file within ~50ish projects and then change a single thing. Therefore it would be amazing to configure it in one single location.
The StyleCop.Analyzers NuGet package works with or without ReSharper. It will give you far better control over which projects it should apply to. You can configure it by right clicking the rules under Dependencies->Analysers->StyleCop.Analysers in your solution explorer:
Once you change any configuration it will create a .editorconfig file for you which you could use to copy to all of your other projects if required.
Related
I'm migrating from Svn externals feature to nuget with a huge project and so far it looks like a bad decision. One of my solution contains 70 projects where most of them contains the same common references (nuget packages).
Previous structure was a common Lib folder per solution which contained all references controlled by svn externals so whenever I wanted to update a version I just updated numbers in tortoise svn and clicked update - quick job.
Currently when I do it from inside Visual Studio it takes 10-20 times longer because I suspect it removes the previous version of package directory from packages, adds new directory, updates packages.config version and updates csproj path. So if I update 7 packages in 70 projects and I have visual studio open it will take much longer. The alternative is to close solution and call nuget update in command-line but it's rather a workaround. Previously path was the same, concept of packages.config didn't exist so the only change was a few lines of code in a text file where we come to the next conclusion - source control changes. Whenever I do an update there is a huge amount of changes which needs to be checked in into source control and I find it a bit messy. I found that there is a flag for nuget install -ExcludeVersion which will exclude version from path so csproj won't be changed and it's a big advantange. Is it a good convention to use it? Is there are support for Visual Studio to use it automatically whenever I install a package? Is there a way to mark a nuget package as "Ignore version in path"? As far as I know the answers for these questions is no, no, no. How do you handle using nuget in bigger projects? Please me know if there is something I can read about nuget how to handle it in bigger projects.
Let's address each issue one by one. Your first question states: Is it a good convention to use it?
This is subject to opinion. If it will break your project to use the ExcludeVersion option on install, then you can't use it. Otherwise, it saves you 70 files on push. The second question states: Is there are support for Visual Studio to use it automatically whenever I install a package?
As far as I can tell (and I may be wrong), there is no way to do this. However, this is going off of quick research, and more information may be found deep inside of the Nuget Config File Defaults (I could not find such a configuration).
I am a little confused as to what you mean by Is there a way to mark a nuget package as "Ignore version in path"?
However, it seems that you mean what Colonel Panic asked in this question: Nuget Packages exclude version in folder naming, in which the answer is no. And lastly, you briefly ask the question: How do you handle using nuget in bigger projects?
Unfortunately, the answer to this question is quite simple: you can't (at least not effectively). Nuget themselves say this in a blog post from October 10, 2014. If you read underneath their "Harmful consequences" section, you can see a lot of the issues that you are running into.
Alright, now onto the solution. I have run into a similar issue with Nuget in the past, and the solution was quite simple. All I had to do to minimize the time was to use Git from command line using Visual Studio's .gitignore (Svn I believe would work too). I know we would all appreciate Nuget to work in these instances; however, this is not the case. As you already use svn, I would suggest not changing. After all, Nuget is really only a macro inside of Visual Studios working on a solution basis.
The answer for my question is project.json. I wasn't aware that I can use it in every project even in WPF. https://oren.codes/2016/02/08/project-json-all-the-things/
I am trying to set up a Visual Studio 2015 solution in the way that StyleCop checks for the C# style and once committed to the source control other developers don't need to do anything else to follow the same style rules and get the same errors/warnings from StyleCop automatically.
As the StyleCop documentation page and GitHub StyleCop describe (both actually say the same) under the title Team Development:
copy all of the files from {Program Files}\MSBuild\StyleCop into a custom folder
in my case under C:\Program Files (x86)\MSBuild\StyleCop\v4.7 there is just one file: StyleCop.Targets
Searching for any StyleCop.dll drives me to another folder (C:\Program Files (x86)\StyleCop 4.7) with many subfolders, dll's, xml, exe, lex...
Now my questions:
Which are exactly the needed files to be uploaded into the project and hence to the source control?
Which are the changes to be done in the configuration project?
Note:
Until now I see the contextual StyleCop menus that allow me to make code analysis and checks.
To use the install, you would need to have each developer install the StyleCop program on their machines, (and on any build server).
There is an easier way... instead use the StyleCop.MSBuild nuget package for each project:
This adds a StyleCop directive to each csproj, pointing at the instance within the packages folder, this means that it is transferable to each dev machine, and any build servers without them needing to do anything.
Then once there is no errors in a project, use StyleCop.Error.MSBuild to keep it that way, again from nuget:
This adds <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> to the csproj, but again keeps it within nuget which I personally find an easier way to track things.
I have done a lot of searching around before asking this question. I am new to developing diagnostic tools and code fixes using Roslyn. I am currently using the Visual Studio 2014 CTP. I have been able to successfully create my first code fix tool. However, when I create another tool in a new solution, it still shows up the Description and fixes for the old diagnostic tool.
Can anyone please explain to me what I am doing wrong? I am rebuilding the solution before I test it out, and as far as I am aware, I am keeping both solutions completely separated. Or can anyone tell me how I can use multiple rules in one solution?
Building the .vsix project created by the templates will install a vsix extension into a special VS hive. These are not automatically uninstalled, so go to Tools | Extensions to uninstall them as necessary.
As SLaks mentioned, you can have multiple diagnostic projects in your solution, but you'll have to update the vsixmanifest in the vsix project to include this new project. If you want the multiple diagnostics to always be distributed together, then just put them in the same project (copy the class structure & exports from the sample).
I keep running into an issue with our TFS build server. I've got 2 projects (both in the same solution), 1 is a WebForms project, running .Net 4.0. The second is an ASP .Net MVC5 project running .Net 4.5. There is also a Silverlight project, but the problem is reproducible with just the first two.
Both of these projects use NuGet packages for various libraries. Sometimes there are different assemblies within a package for their respective environments. A .Net 4.0, 4.5, SL assembly, etc.
The build server seems to dump all of the libraries required into a single folder, then pulls from that to build the solution. This causes problems in many cases, with the wrong project getting the wrong assembly version. This does not occur locally, only on the build server. I can't figure out what I need to do to keep this from happening. Any ideas?
Yes, I hate this standard behavior, but TFS will output everything to the same folder by default, and then you will get various errors depending on which order msbuild compiles your projects if you have references with the same name or even project outputs with the same name.
The easiest workaround is to use the AsConfigured option on the Process tab, '2. Build' -> 'Output location' of the build definition window. This keeps your normal source structure intact, but I think you will lose support for automatically dropped outputs (i.e. you will have to provide a script to do that yourself). If you are only using TFS Build for validation, this is the cleanest approach.
You can also use the PerProject setting and split up your projects into two distinct solutions, perhaps suffixed by platform (we've done that numerous times in our company). Then, you specify both solutions to the build process and it will create two separate folders in the output, one for each solution.
This is all assuming you are using TFS 2013. In TFS2012, there is a similar option but it is in '3. Advanced' -> 'Solution Specific Build Outputs'. You will probably have to go this route if you are using TFS2012 or you will need to modify the default workflow yourself to add your own logic.
EDIT:
From your comment to the other poster I see you are using TFS 2010. Well... I think this was absolutely not supported at that time, I remember having similar problems, but we upgraded to TFS 2012 and all was well.
I think your only option is to either create two separate build definitions and build each solution that way, or you will need to checkout the xaml workflow and edit it with your own logic. Perhaps downloading the TFS2012 template and "porting" it to TFS2010 would be a better approach since at least you would not be reinventing the wheel that way.
Explicitly setting dependency in VS2010 between unmanaged C++ project and C# project is honored in VS2010, but dependency is ignored in MSBuild 4.0.
It is impossible to add a reference to unmanaged C++ project from C# project, afaik.
How do i ensure correct build order if a solution contains unmanaged and managed projects?
MSBuild has a bug in it and doesn't correctly honor project dependencies added at the solution level. Take a look at http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/80cc6447-b720-4806-8395-7c257b207613/ and https://connect.microsoft.com/VisualStudio/feedback/details/613284/msbuild-4-does-not-respect-build-order-when-building-a-solution
A posting by Microsoft on the connect page indicates that its a bug in the 64-bit version of MSBuild. Try switching to the 32-bit version to see if that solves the problem.
If you can't do that, or it doesn't work, there are two other options. Neither of them are ideal.
The first option would be to manually edit the SLN file and change the order the projects appear in the file to match the build order you want. I imagine Victor's solution would be a much better idea, since additional changes to the solution file could end up overwriting the changes again.
The second option would be to manually export the MSBuild "metaproject" for the solution and edit the build order directly and add any other customizations you need. From what I've read, even at Microsoft they don't "dogfood" solution compilation - instead, they avoid them completely during builds and use custom MSBuild files instead.
To generate the metaproj, set the environment variable MSBuildEmitSolution to 1. After running MSBuild on the solution and you should see a ".metaproj" file in the same directory - it contains the script that MSBuild generates in-memory to compile the solution. You should be able to make the necessary edits, check it in, then set the build server to compile it.
The issue will disappear in the next release of Visual Studio. The Microsoft Connect page has a posting from Microsoft that it will be fixed in the next release, and rumor has it they're getting rid of .sln files and replacing them with proper MSBuild projects.