msbuild: init at 15.6 #43680
msbuild: init at 15.6 #43680
Conversation
|
Don't merge this! It looks for a file in the mono installation whenever it tries to build a project, but it's not there. I'm not sure where that file is supposed to come from. |
|
This file exists, and is in a subdirectory. Weird. |
|
I have an untested fix locally, but it's gonna take a minute to build Mono. |
|
It built, having some difficulty testing it, will push in a few minutes. |
|
Was compiling something, OOMKiller killed nix-env. One minute... |
|
My fix didn't work, it should be pretty simple to fix, though. Can someone with a machine better at compilation try to fix this? Just try to compile any C# application. Here's the error: The failed fix was to symlink that in Mono's postInstall, as that directory is there in Mono, just at a different path. |
GrahamcOfBorg
added
8.has: package (new)
|
I think I have a working fix, but I had a power outage while I was compiling Mono. It might still be a little while. |
|
Update: It now attempts to build C# (yay!) but is failing to search the GAC (boo), where the standard library is located via. |
GrahamcOfBorg
added
10.rebuild-darwin: 11-100
10.rebuild-linux: 101-500
and removed
10.rebuild-darwin: 1-10
10.rebuild-linux: 1-10
labels
|
I have a fixed version, but am having some trouble rebasing onto master. It'll be a few minutes. |
|
help |
|
Fixed version. |
| '' | ||
| # Make MSBuild stop complaining | ||
| + '' | ||
| cp $out/lib/mono/xbuild/14.0/Microsoft.Common.props $out/lib/mono/xbuild/15.0/Microsoft.Common.props |
There was a problem hiding this comment.
Was this an error or a warning? If it was just a warning i think it’s best to not mess with this stuff.
There was a problem hiding this comment.
I think I've encountered the same error also. When compiling a project, the compilation would fail with
Microsoft.Common.CurrentVersion.targets(3446, 5): [MSB3491] Could not write lines to file "/Debug/ClientLib.csproj.CoreCompileInputs.cache". Could not find a part of the path "/Debug/ClientLib.csproj.CoreCompileInputs.cache".
Microsoft.Common.CurrentVersion.targets(5101, 5): [MSB3191] Unable to create directory "/Debug/". Access to the path "/Debug/" is denied.
(it attempts to write to the filesystem root, because a prefix is not set correctly).
I resolved the same thing by 1) downloading msbuild and unpacking msbuild, 2) setting it in jetbrains.rider in GUI in Use custom MSBuild version to
/home/jdanek/Downloads/msbuild/MSBuild.dll
and 3) adding to my .bashrc the following
export MSBuildExtensionsPath=/home/jdanek/Downloads/msbuild/Extensions
There was a problem hiding this comment.
Update on this: I cannot recall, but I believe (knowing me probably not) the upstream Mono maintainers told me to apply this. I completely forgot about this until yesterday, though, you might have to check.
|
|
||
| unpackPhase = "dpkg-deb -x $src ."; | ||
| installPhase = " | ||
| substituteInPlace usr/bin/msbuild --replace /usr/bin/mono ${mono}/bin/mono |
There was a problem hiding this comment.
FWIW you can do multiple replaces in one substituteInPlace.
| sha256 = "0jgw80p9dr9mi40i8vy22y3b5d4byr26s9gvs5xjjgdzqdrlj9fm"; | ||
| }; | ||
|
|
||
| buildInputs = [ dpkg ]; |
There was a problem hiding this comment.
This Should go in nativeBuildInputs.
|
I made those changes, but couldn't test them because I haven't built my patched Mono off master. |
|
It works. I don't know how to remove the "Merge branch 'master' into master" commit, GitHub created it (from the web UI). This would be really nice for 18.09, it would drastically improve .NET support. |
|
@samueldr (pinging because of Discourse post) This would be nice for 18.09. |
|
👋 hi! Thanks for your contribution. I have checked the PR as best as I could... but lacking the experience and knowledge with I have looked online for a "hello world" project for msbuild, not really confident this one strains Mono Maintainers, assemble! @thoughtpolice @obadz @vrthra you are listed, any one of you could take a peek and either yay or nay? |
|
The problem was actually with C# compilation. The last line of this example was what needed the fix, and it should be a simple testcase (note that you must pass the Gtk option on line 3 for Linux support): https://github.com/picoe/Eto/wiki/Quick-Start#dotnet-new The Eto.Forms tests will likely trigger the bug, but I am unable to check right now. If necessary, I can, though. https://github.com/picoe/Eto/tree/master/test/Eto.Test For a project I have worked on, but not tested with MSBuild (though logic dictates that it "should" encounter the bug), see: https://github.com/EverestAPI/HookedMethod |
|
Also, xbuild implements a subset of MSBuild. As it was deprecated a few years ago, the subset of current MSBuild features is much smaller than it used to be; the project format was completely changed to be (more) human-editable a little while ago, and xbuild never added support. |
|
Hi, Tried to stumble my way through the links you sent... I was pretty unsuccessful! This does not mean this PR is wrong... I still don't know how to verify, especially verify the change for the copied While in a checkout of this PR, I entered a shell: Then, I tried the instructions in the Eto quickstart (dotnet new). This is where I'm uncertain of the results. ✂️ elided due to lengthThere are three errors. I do not know the actual expected result, as I do not know about either .NET or Eto. This could be expected in a new project, but I'm thinking this shouldn't happen. I'll ping again the mono maintainers people @thoughtpolice @obadz @vrthra for help in reviewing. @leo60228 if you have an example transcript of what you're doing to verify, and lightly explain the steps, I could also boost my confidence in this PR following it. |
|
This is weird. Can you try running |
|
Ah, just dropping I have confirmed that your added file does (seemingly) fix an issue. This was used to verify: With and without the added line to generic-cmake. EDIT: How was the fix decided upon? Was this a recommendation from some other issue? (I'd like to keep a trail leading to an upstream issue, if there is one.) |
| cp -r . $out | ||
| rm $out/env-vars | ||
| cp -r ${mono}/lib/mono/msbuild/15.0/bin/Roslyn $out/usr/lib/mono/msbuild/15.0/bin/Roslyn | ||
| cp -r ${mono}/lib/mono/4.5 $out/usr/lib/mono/4.5 |
There was a problem hiding this comment.
Why is it necessary to copy stuff from mono? Wouldn't it be better to use the existing files from mono? This adds around 100MB of duplicated stuff.
| substituteInPlace usr/bin/msbuild --replace /usr/bin/mono ${mono}/bin/mono --replace /usr/lib/mono/msbuild/15.0/bin/MSBuild.dll '$(dirname $0)/../usr/lib/mono/msbuild/15.0/bin/MSBuild.dll' | ||
| mv usr/bin . | ||
| cp -r . $out | ||
| rm $out/env-vars |
There was a problem hiding this comment.
Extracting to a subdirectory instead of into cwd wouldn't bring in the env-vars file.
A simple fix, using a subshell, which doesn't change your commands too much
diff --git a/pkgs/development/tools/build-managers/msbuild/default.nix b/pkgs/development/tools/build-managers/msbuild/default.nix
index 08931b2edfc..28d42fa07da 100644
--- a/pkgs/development/tools/build-managers/msbuild/default.nix
+++ b/pkgs/development/tools/build-managers/msbuild/default.nix
@@ -14,12 +14,14 @@ stdenv.mkDerivation rec {
dontConfigure = true;
dontBuild = true;
- unpackPhase = "dpkg-deb -x $src .";
+ unpackPhase = "dpkg-deb -x $src build";
installPhase = "
+ (
+ cd build
substituteInPlace usr/bin/msbuild --replace /usr/bin/mono ${mono}/bin/mono --replace /usr/lib/mono/msbuild/15.0/bin/MSBuild.dll '$(dirname $0)/../usr/lib/mono/msbuild/15.0/bin/MSBuild.dll'
mv usr/bin .
- cp -r . $out
- rm $out/env-vars
+ )
+ cp -r build/ $out
cp -r ${mono}/lib/mono/msbuild/15.0/bin/Roslyn $out/usr/lib/mono/msbuild/15.0/bin/Roslyn
cp -r ${mono}/lib/mono/4.5 $out/usr/lib/mono/4.5
";
|
I can't currently fix this, I won't have access to any NixOS system until Monday night. Can you check if those work? I'm fine with you adding them to my commit. |
|
I am unfortunately unable to help out with this, but this would be fantastic to have merged (since msbuild is required to be able to use C# support in VScode I imagine this would help adoption as well). |
2 similar comments
|
I am unfortunately unable to help out with this, but this would be fantastic to have merged (since msbuild is required to be able to use C# support in VScode I imagine this would help adoption as well). |
|
I am unfortunately unable to help out with this, but this would be fantastic to have merged (since msbuild is required to be able to use C# support in VScode I imagine this would help adoption as well). |
|
I deleted and recreated my fork, which appears to have broken the PR. Recreating... |
|
@jdanekrh I'm actually blocked by this error message on vscode: Where the directory Here's the same issue report in OmniSharp: dotnet/vscode-csharp#3180. The workaround reported there is to directly edit the |
|
@billksun Let me try to reproduce that for myself. So far, i got this $ dotnet new -i "GtkSharp.Template.CSharp"
Getting ready...
Restore completed in 1.79 sec for /home/jdanek/.templateengine/dotnetcli/v2.2.401/scratch/restore.csproj.
[...]
$ dotnet new gtkapp
The template "Gtk Application" was created successfully.
$ ls
MainWindow.cs MainWindow.glade Program.cs project.csproj
$ dotnet run
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Gtk.Application' threw an exception. ---> System.DllNotFoundException: Gtk
at GLibrary.Load(Library library)
at Gtk.Application..cctor()
--- End of inner exception stack trace ---
at Gtk.Application.Init()
at project.Program.Main(String[] args) in /home/jdanek/project/Program.cs:line 11
dotnet run 4.42s user 0.76s system 68% cpu 7.542 totalI run vscode with |
|
There is msbuild, mono, and dotnet-sdk as separate packages, that nevertheless interact in some ways both at build time and then at runtime, maybe even circularly. It might be hard to untangle this when these packages cannot share files in a FHS filesystem. I don't know enough about .net to be much help there. Or maybe could be sufficient to package omnisharp for nix and fix things there? My #66134 does not seem to help with this omnisharp issue, btw. |
|
I think I got it. Give OmniSharp the MSBuildExtensionsPath from #66134. In the example project from above % cat omnisharp.json
{
"MsBuild": {
"MSBuildExtensionsPath": "/nix/store/sn4h4a3qbp11yng2621yqzk16blvn6bw-msbuild-16.3+xamarinxplat.2019.07.26.14.57/lib/mono/xbuild"
}
}kill vscode and rerun OmniSharp is not complaining with errors on startup any more, and auto-completion in C# is working. |
|
@jdanekrh, this doesn't seem to work for me. Although I put omnisharp.json file in my project root directory and used the path for my mono installation So it seems that omnisharp is not picking up on the config file. |
|
@jdanekrh, will do |
|
@jdanekrh, using msbuild from #66134 works! |
Motivation for this change
xbuild, which is part of Mono, is deprecated, in favor of the recently open-source MSBuild used on Windows. MSBuild has an incredibly complicated build system, which appears to fail silently on non-FHS systems. Thus, I used the official Ubuntu binaries. These require relatively little patching, as .NET is a bytecode language, so patchelf is not necessary. I don't have a Mac to test, but it may work on MacOS as well for this reason. This is definitely a stopgap; however, MSBuild's custom build system will require extensive work to be used, or even emulated, on NixOS.
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)