search

realvizu / NsDepCop

NsDepCop is a static code analysis tool that helps to enforce namespace dependency rules in C# projects. No more unplanned or unnoticed dependencies in your system.
GNU General Public License v2.0
200 stars 32 forks source link

Support .NET Core #34

Closed ausol closed 3 years ago

ausol commented 6 years ago

Does NsDepCop work for .NET Core 2.0 projects? I was not able to find any specifics about supported .NET versions here on the GitHub pages.

Since I could not find it specified, I just went on and tried it. It seems to work OK from Visual Studio 2017, giving me the build errors I expected when I try to reference disallowed namespaces, etc. But when building from the command line by dotnet build, I get the following error:

`

\.nuget\packages\nsdepcop\1.7.1\build\NsDepCop.targets(5,9): error MSB4062: The "Codartis.NsDepCop.MsBuildTask.NsDepCopTask" task could not be loaded from the assembly \.nuget\packages\nsdepcop\1.7.1\build\..\tools\NsDepCop.MsBuildTask.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [.csproj] ` I guess [this issue](https://github.com/Microsoft/msbuild/issues/2111) might be relevant here.
realvizu commented 6 years ago

Thanks for the feedback. I've never used it with .net core so I'll have to do some research to understand the problem and try to fix it. And thanks for the issue link, I'll start on that path. But first I'll have to complete v1.8 development, so it will take a while. Btw if you feel like contributing please let me know!

penenkel commented 5 years ago

I have looked into this to see if it would be a simple fix or not. In short: it's not.

The issue linked above is indeed the root cause: ".NET Core MSBuild cannot load tasks built against MSBuild 4.0". Unfortunately it doesn't look like this will ever be resolved.

The recommended action is to multi-target the task implementation. I have found a nice HowTo by Nate McMaster on this.

Of cause for this to work the task implementation must be compilable against .Net Standard. For NsDepCop this concerns at least NsDepCop.MsBuildTask and NsDepCorp.Core. IMHO this also requires switching to the new .csproj format, but that may not necessarily be true. (On this there is also a nice article by Nate McMaster. Using this tool reduces the required effort somewhat.)

After I had come this far I ran into the next hurdle: .Net Remoting is not part of .Net Core/Standard and never will be. There is apparently no 1:1 replacement available. Recommendations range from low-level sockets or pipes to HTTP. The most promising replacements seem to be gRPC or StreamJsonRPC (which is apparently used by VS). See this issue for more information.

Well, this is how far I have come at this point. I'm hoping that you'll be open to replacing .Net Remoting with a suitable, .Net Standard compatible alternative so that the netcore cli version of MsBuild can be supported.

In any case, thank you for creating such an incredibly useful tool.

realvizu commented 5 years ago

Thanks a lot for this analysis.

Dear Community, help with the implementation would be much appreciated!

lineker commented 5 years ago

Any news on this?

realvizu commented 5 years ago

Nothing new. Unfortunately I don't have time for this project nowadays and nobody volunteered to help out.

realvizu commented 4 years ago

Should also check this blog post to see if it's applicable: https://natemcmaster.com/blog/2017/11/11/build-tools-in-nuget/

jshield commented 4 years ago

I've made a stab at this, Ill publish what I have so far tomorrow with any luck.

Essentially I have retargeted Core, MsBuildTask, Nuget and ServiceHost to netstandard2.0, and netcoreapp.

I've switched MsBuildTask to use InProcess at the moment with a few nuget hacks in place to make sure it can load all the appropriate dlls into the MsBuild Context.

I am attempting to replace the .Net Remoting with serialization over StdIn/StdOut between the parent and child processes. Some success, difficult without pulling in serialization assemblies into MsBuild.

Long and the short of it is, NsDepCop targeting netstandard2.0 can dog food NsDepCop.MsBuildTask targeting Microsoft.Build.Tasks.Core 16.4.0 for Analysis, this gets us to where we (Zoodata) want to be.

realvizu commented 4 years ago

Thanks a lot for your efforts! Can we expect a PR?

jshield commented 4 years ago

Hey Ferenc,

Apologies for not getting back to this sooner. Been busy moving and work has been pretty heavy going.

I haven't managed so far to solve the .Net Remoting replacement yet, I'll leave that to someone else I think at this stage.

I'll push up my repo and send through a PR today or tomorrow but it will probably need additional refinement to get it upstream without breaking others.

Thanks for the brilliant tool.

realvizu commented 3 years ago

A new version (v2.0) release candidate is out on NuGet. Made a radical change, dropped the custom MsBuild task, the out-of-process service host and the Visual Studio extension. The new version is a pure Roslyn analyzer which works both in VS at code editing time and at build time (both with msbuild and dotnet). Tested with .net core 3.1, .netstandard 2.0, .net 5.0 and .netframework 4.71 projects.

Please try the v2.0.0-rc1 NuGet package and reopen this ticket or file a new one if anything is wrong.