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.
Related
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.
I'm wondering if adding .csproj files in the git history is really useful / best / bad practice
(Currently, I'm using git for private repositories)
Thanks!
Short answer: You definitely need .csproj files in your git history.
Long answer: Here's how to answer a question like that. Make a copy of your solution folder. Delete any files you wonder if they should be included in the git history. Try to build and run your code. If you can't, that means they are needed in git, and vice-versa.
In this case, you would discover that your project will not build without the .csproj file, hence that file must be in git.
It's also important to remove from git files that are not needed to build and run the project, such as files that are generated as part of the build process.
For the most part, this work has been done for you already, for example https://github.com/dotnet/core/blob/master/.gitignore has a list of directories and extensions that should be ignored for .Net Core projects. Other platforms/languages have similar .gitignore files posted.
In addition to the answer above, it helps to know what project files are:
When you create and build solutions in Visual Studio, Visual Studio uses MSBuild to build each project in your solution. Every Visual Studio project includes an MSBuild project file, with a file extension that reflects the type of project—for example, a C# project (.csproj), a Visual Basic.NET project (.vbproj), or a database project (.dbproj). In order to build a project, MSBuild must process the project file associated with the project. The project file is an XML document that contains all the information and instructions that MSBuild needs in order to build your project, like the content to include, the platform requirements, versioning information, web server or database server settings, and the tasks that must be performed.
Ref to more details (.Net): Understanding the project file
Similarly for .Net Core: Project files
Hence the reason why (emphasis mine):
In this case, you would discover that your project will not build without the .csproj file...
Hth...
I am currently trying to automate our .NET builds and have currently run into a snag. When building the project in Visual Studio on a machine with a InstallShield 2016 Professional License, everything builds fine. However, when trying to use MSBuild to build the VS Solution on a machine with InstallShield 2016 Standalone, the resulting MSI does not have a required DLL or a Custom Action. Meanwhile, trying to build the .ism using Iscmdbld results in the inability to find the Primary Output of the csproj's, Even after building in Devenv
If you are using project output groups (like Primary Output), your choices are limited. You have to use either the VS integrated build (via devenv), or MSBuild; iscmdbld is unable to resolve project output groups.
Your other alternative is to change from project output groups to using static (or dynamic) file links that don't require Visual Studio's knowledge. I tend to prefer static links, as it's easy to tell exactly what's in the project. More importantly, with static links you can't silently lose files that you'd previously added, thus it's easier to avoid potentially breaking component or upgrade rules.
Hopefully, this isn't too old to be of use. InstallShield is the absolute worst, I know.
If you edit your .isproj in a plain-text editor, you'll see that it's just a regular MSBuild script. You'll see that there is a lot of commented out stuff that explains (poorly) things you can add to it. Find the ItemGroup that contains the explanation about "ProjectReference items" and add a node of the following form:
<!-- The ProjectReference items refer to any Visual Studio solutions you want to automatically probe for Project Output Groups. -->
<ProjectReference Include="..\Path\To\Your\Proj.csproj">
<Project>{2d3f37cc-0e93-4673-a3df-59c556185f71}</Project>
<Name>Name Of Project As It Appears in VS</Name>
</ProjectReference>
After adding the above to all of my .isproj files, my automated build worked fine. Why the idiots at InstallShield never saw fit to add this capability to the UI, I'll never understand.
Unfortunately, I don't have any answer to the Custom Action problem, if it's not related to the above.
I would like to make a backup copy of my Visual Studio 2013 MVC application which is only the source code. Such that I could open the solution on a new machine and have it compile after NuGet has downloaded the necessary packages and so on.
I realise that if the project was in TFS or similair I could go to the new machine and download it like that, however I am looking for a file copy solution.
Now while I could ZIP up the entire folder including binaries that seems like a sledge hammer approach. Having looked around there does not appear to be an easy way to do this. Has anyone got a solution or a utility I may have missed?
Use a version control system such as TFS, Subversion, PlasticSCM, git whatever. Seriously. Distributed VCSs like git or Mercurial will let you transport the whole repository easily.
If you insist on a pack&go approach, the ZIP tool of your choice will, most likely, support include / exclude rules based on file name patterns. For example, in Total Commander it's easy to exclude bin and obj folders.
I am not sure how this feature is called in English but there is something like Clean solution in Visual Studio. This will delete all the binaries and stuff that can be generated. I am not sure it will also delete NuGet downloads but you may give it a try. Afterwards, you can simply copy the project or solution folder.
I have a C# project in MS Visual Studio 2008 that I would like to share on Google Code...I am not sure exactly which files I should be sharing on Google Code if I want to involve other contributors? What I am exactly unsure about is whether to share the entire solution folder or just the .cs files? And if it's the latter how does a contributor go about building the solution and the directory structure?
Thanks
Generally I would include the project file(s) and solution file(s) as part of the source code in a team environment (such as at work), especially if they contain anything that's needed for the proper building of the code (build events, DLL references, etc.). The user file(s) and suo file(s) and stuff like that aren't needed, those are user-specific. But this is in an environment where it can be safely assumed that everybody is using Visual Studio, even the same version.
The code itself doesn't need the project/solution files to be built, and the less you can depend on them the more open-source-friendly the project really is. If the code can be properly built from the command line, or with a tool such as NAnt, then an open source project may be better off with that. So, just from a separation of concerns perspective, try to keep the dependency on the project file(s) as light or non-existent as possible.
Overall, including the project file(s) and solution file(s) is fine if your intended audience is expected to be using Visual Studio.