siegfriedpammer
commented
7 years ago Please see #833 for our final resolution, which introduces an independent project file for .netstandard. This is a workaround in order to avoid all the problems with multiple DLLs copied to the output folder and so on. Please be aware that the resulting .net std package is built, but not yet tested. The tests still use the old-style projects.
First of all, migrating to .NET Standard was not as simple as it is promoted by MS. Wasted more than 20 hours on different quirks. And yes, it was very frustrating...
Attempt no. 1:
First we migrated the ICSharpCode.Decompiler.csproj to the new format and actually planned to use only that in the whole solution. We added all the necessary nuget packages and except for one small change, we could use our codebase.
Important: If you use AssemblyInfo.cs in your project and have some tooling attached to generate version information, I'd recommend adding <GenerateAssemblyInfo>false</GenerateAssemblyInfo> to your new .net standard project, that way you can keep using the old-style AssemblyInfo.cs.
The next thing was getting the unit tests to work: We followed Scott Hanselman's advice, which worked fine until we tried to actually run the unit tests in Visual Studio. We got lots of strange exceptions, like MissingMethodException or FileNotFoundException telling us that something was missing. Except it wasn't, just the .NET Standard implementation got confused it seems.
Attempt no. 2:
Then we migrated one project after another from good ol' .NET to the new project format, hoping that it would solve our problems. But, we couldn't quite port our unit tests, because we are doing some advanced stuff there, like compiling C#, assembling IL and running nested unit tests (We're talking about a decompiler, testing it is not simple). One strange thing was: The .NET Core Test Runner wants to inject a custom Main method and implicitly turns the project into a console app (tooling bug?), which in turn fails to compile because we use a lot of Main methods in our test cases which get compiled during tests.
Then we added a second target using the TargetFrameworks attribute, so we just could use net461 for all the other projects. We ended up even converting our WPF UI to the new project format, despite the fact it does clearly not yet officially support WPF, using some tricks (https://stackoverflow.com/questions/43693591/how-to-migrate-wpf-projects-to-the-new-vs2017-format and https://github.com/dotnet/project-system/issues/1467). And it worked! Except for the XAML/BAML unit tests, we could not get those to compile, because the InitializeComponent methods were not recognized. But we don't understand why, because it worked with the UI project and we were using the same tricks in both project files.
At that point I decided to revert the XAML/BAML tests to the old project format and tried to get it to play nicely with the other projects. And in the end it worked, I had to remove some references and some code. And then I pushed my changes, to see if the build server was configured properly. And it failed...
Attempt no. 3:
Please see #833. First we introduced a new project with .netstd.csproj as suffix. It resides in the same directory as the old-style Decompiler library and compiles the same source files. While trying to get it to work, we were running into the following issues:
- We needed to enforce that the netstd project is built before the normal projects, because they are both sharing the same intermediate output folder (see dotnet/project-system#1935 and related issues). This involved adding a build dependency, so the old project depends on the netstd one.
- The above issue requires us to remove the intermediate output directory after netstd is built (via plain old del command in a post build task), because otherwise the old project cannot be built any longer. We cannot do this the other way round because the
project.assets.jsonis only generated by nuget. Any attempt of usingIntermediateOutputPath,BaseIntermediateOutputPathor the newProjectAssetsFileproperties results in either one or the other project "forgetting" about builtin types among other things. - AppVeyor/msbuild: yes, it does not respect any build dependencies properly, that's why we had to disable parallel builds, in our case this is not a big deal.
sharwell
christophwille
Please see https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support
Minimum Framework compat will be 4.6.1 and Core 2.0. Dev dependency: VS2017 15.3 minimum plus .NET Core 2.0 SDK.