-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retarget ICS.Decompiler to .NET Standard 2.0 #831
Comments
Update ICSharpCode.Decompiler.Tests.csproj to new project format. Seems like we cannot make the tests work with .NET Standard/.NET Core because we have some special cases: - tests for UndocumentedExpressions depend on the full framework - 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. - Needed to update all the Nuget packages: most notably DiffLib
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 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 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 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:
|
📝 I'm reading through your comments. Is this the best place to chat about it if I have questions on the approach(es)? |
|
❓ Do you have branches with "Attempt 1" and "Attempt 2"? I'm assuming #833 represents Attempt 3. |
Unfortunately I killed the other attempts by resetting (push --force) everything. We'll try to set up separate branches for the other attempts as well. |
@sharwell After upgrading the Mono.Cecil submodule in the repo to the latest commit, AppVeyor fails again, guess this is because Mono.Cecil now uses .NET Standard as well. On my machine this does not happen and in the ILSpy.sln file we specify
|
@sharwell I luckily had copied the directory to the side from yesterday's attempt 2. The branch for you is https://github.com/icsharpcode/ILSpy/commits/netstandard-build-troubles - the last commit was us trying to get AppVeyor to work. If I remember correctly: on the first build in VS, it doesn't find Longset private member (although AssemblyInfo.cs has the necessary definition). Right-click, build ics.decompiler and it is fine. From then on, VS locally is fine (except for a rare race condition on Clean for Cecil). AppVeyor was more stubborn: never found Longset and totally didn't understand RevisionClass from AssemblyInfo.cs. The pertaining ci link: https://ci.appveyor.com/project/icsharpcode/ilspy/build/1.0.405 |
@siegfriedpammer running the commands Appveyor uses (dotnet restore ilspy.sln, msbuild "ILSpy.sln" /verbosity:minimal ) exhibits the same problem. So it is definitely a msbuild tooling problem. |
@christophwille Thanks, I'll take a look! |
There's the problem. I totally overlooked it originally. I'll fix the PR. Edit: Nope, AppVeyor is using the correct command already (nuget, not dotnet). |
I fixed it! 🎉 |
Built from commit 949790d I have uploaded a test Nuget package for testing purposes (Nuget, xplat): https://www.nuget.org/packages/ICSharpCode.Decompiler/3.0.0-alpha1 Please note the language support at #829 - this package has less decompilation support than the officially released one. |
Super-small sample https://github.com/christophwille/ilspy-console-netcoreapp but please see #845 |
This was fixed in the new decompiler engine (which just landed on the master branch). |
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.
The text was updated successfully, but these errors were encountered: