I'd like to add rulesets to my project following the fashion I can see in the EFCore and MachineLearning projects.
I have read through the Roslyn Analyzers doc but I didn't find a file or a method where one can get the list of avaialble analyzers. Ofcourse, I can copy and paste what I can see in the above examples, but this way I won't have a sustainable method to maintain when new rules are released.
So, the question is how can I get a list of rules in a ruleset format?
Update:
I opened my solution in VS which has a ruleset editor, but seemenhly it writes the rules into file randomly.
I also asked the StylecopAnalyzers guys.
Maybe I am overlooking something here but I can't seem to find a good way to parse a solution file and programmatically exclude some projects (.vcxproj) from the build. Many SO posts reference the SolutionFile class in Microsoft.Build.Construction to enumerate the list of projects and their configurations. In fact there is even a IncludeInBuild property that tells me if a particular configuration is selected to be included in the build (see: https://msdn.microsoft.com/en-us/library/microsoft.build.construction.projectconfigurationinsolution.includeinbuild.aspx)
However I can't seem to find a way to alter/create-a-copy-of the solution file and do a moral equivalent of setting the IncludeInBuild property to false for some projects.
Is this not possible today?
When I create C# project in Visual Studio 2010, file Microsoft.CSharp.targets is included.
Is any documentation available for it?
Which targets in it, which properties are used?
It is especially useful when editing build script manually without VS.
The file with targets could be investigated manually (what I do from time to time).
But in such case it is not clear what is a matter of changes, what is by specification and what is no.
Everytime I need something about Microsoft.CSharp.targets I found it in different places.
I have not found "one place" with all described.
Does complete reference available?
Thanks.
No specific documentation I know of, it is an implementation detail for C# projects. You can find plenty of documentation about MSBuild in the MSDN library, the Microsoft.CSharp.targets file just contains targets that are specific to building a C# project.
The most important targets it implements are Build, Clean and Rebuild. They directly correspond to the commands you find in the VS build menu. The .csproj file merely sets properties that affect the outcome of the general targets. All of this is readily available on your machine, you can look at .targets files with an editor. There's just a whole lot of it and it is isn't exactly that easy to read, the concept of XML as a programming language is a bit, well, flawed. No debugger either.
It is a well known issue with Resharper that it fails to recognize generated C# files using Custom Tasks (making intellisense fail). Does anyone know how to fix this without adding the files to the project?
(BTW, including the generated files in the project or creating a separate assembly and other such flawed suggestions are totally out of the question).
Can we write a Resharper plugin for this? We have a fairly large number of developers that cannot use Resharper, so this would well be worth the effort.
Can we somehow add the obj/*.g.cs files to
Resharpers non msbuild based csproj parser (lurking somewhere within Resharper)?
Is the method used by Resharper on how to resolve the list of .cs files to include documented somewhere?
As this issue is experienced and reported again and again for years, surely there must be someone who has cracked it by now?
I found an extension for Resharper: ReSharper.ExternalCode.
Tip for Antlr: add obj\Debug in Resharper -> Code Inspection -> External Code and reload solution.
It's works for me.
It's not code-related but IDE related. I'm working on a .NET solution with about 35 different projects. These projects need to be re-organized into a new folder structure. Why? Because about 10 of those will be removed and the rest will be divided in more logical units.
One way to do this is by creating a new solution, Drag&Drop the projects into a new folder tree within the Windows explorer and then just add them to the new solution.
To be honest, that sounds dumb!
Is there a way to just move projects into different folders from within the IDE? I've tried to "save as" the projects but the IDE won't accept a different folder.
It's irritating but because there have been a few wrong choices in folder names, I'm now stuck with those names.
Example: Right now I have a project main folder which contains child folders named "Client", "Server", "Business", "Database" and whatever more. Within those child folders, there are more child folders, each a three-digit number. Within each numbered folder there's a project which is named in some logical way, like Company.Business.Customers with additional logic within this project.
The problem is that not all projects now follow this naming convention and I consider it obsolete.
A project like Company.Business.Customers should just be in a folder named Company.Business.Customers in the project root so it's easier to recognize. The name already makes it clear that it's a business class for this project. The clear division within client classes, business classes and whatever more just needs to be arranged within the solution, but I want to flatten the file structure. (And remove some obsolete projects.) Basically, I'm not refactoring, I'm just cleaning up.
VS2008 doesn't seem to have such an option, though...
Fire up notepad.exe and open the .sln file. And start Windows Explorer, navigate to the solution directory. Observe how the .sln file content matches the solution structure. Edit the entries, make the corresponding change with Explorer. Backup first.
I don't think there's an easy answer here. Your main problem is going to be that Visual Studio (or .NET) doesn't care if you have classes that belong to a different root namespace sitting in a project.
So if you have a project called Project.BusinessObjects and another project called Project.DataObjects there is nothing stopping you from putting a class called Project.BusinessObjects.User into the Project.DataObjects project.
I don't know of any way of doing all of this without a lot of manual work. Resharper will help quite a bit if you use the 'namespace rename' feature, but you're still gonna end up with a lot of grunt work.
Also, be VERY wary of doing this in conjunction with version control systems. You have to know your version control system really well to know how it's going to react to such major refactoring.
Other than that, what you are describing doing is not all that difficult. You do have to edit the solution files and maybe the project files by hand, and you might need to remove a project from a solution and add it again when it's under the right directory.
I would make a backup, and then refactor away. I think it is a mistake to think that you can do everything you need from the IDE, though. And if you do what you describe from the IDE in a source control system that uses the old Visual SourceSafe API, you will certianly (guaranteed) mess up your bindings, that API is just not made for moving (or renaming, for that matter) files around in the way you describe. The best way to do this under that scenario is to remove all source control bindings and then re-add the reorganized solution back in.
It's not that difficult, you just have to prepare (do a backup) and experiment until you get it right.
I don't think there's any way to do this from within Visual Studio, and as #gmagana points out it's going to be very difficult to do if the files are under version control.
However, it is possible to do it manually.
Start by creating the new, desired folder structure - ignore the .csproj files and solution files for now, and more the .cs files you're interested in into the new structure.
Now, fire up Visual Studio, and create a new, empty project. If you have different types of projects, you might want to create one new, empty project for each type. This will leave you with an empty .csproj file, and a .sln file with just one project.
Copy the empty project file to where they're needed, and rename them as needed. You can edit them and change the Assembly name and default namespace if you want, or wait until you're done and change the settings with Visual Studio.
Finally, edit the .sln file, and remove the Project section. Copy the empty .sln file to where you want it, and open it up in Visual Studio. Now go and add each of your existing projects to the new solution.
Within each project, click the "show all" button, and start including all the files you've copied into the project structure. Resolve missing dependencies, change the namespaces and assembly names for the project, and make sure that the code files don't specify a namespace you don't want. Repeat until done.
Once you get the new solution to build, it will be helpful to open up the DLLs in Reflector in order to ensure that you haven't missed any namespace declarations in the code file - if you're trying to get to a point where there's a 1-1 correspondence between the DLL and the namespace, or even ensuring that no namespaces are split between DLLs, Reflector is your friend.
Good luck.
I've used the following solution to solve my problem:
I started with a new, empty solution in a new folder.
For every project that needed to be moved, I used the Windows explorer to create a child folder in the solution folder, this time with the proper name.
I copied the projects from their original location to their new folders.
I added all the (moved) existing projects from their new locations.
In the Solution Manager, I renamed the projects to a better name.
I fixed the project properties and other settings for all projects.
This did clean up the whole project quite nicely. I then added the whole project to Vault (Version Control System) and once it was in the VSS, I deleted the folder again (actually, just renamed it first) and retrieved it back from the VSS system so any obsolete binaries and other garbage was gone too.
It's a lot of work, but the result turned out exactly what it needed.