Bug 42938 - Can't build netstandard PCL library with xbuild
Summary: Can't build netstandard PCL library with xbuild
Status: VERIFIED FIXED
Alias: None
Product: Tools
Classification: Mono
Component: xbuild (show other bugs)
Version: 4.6.0 (C8)
Hardware: Macintosh Mac OS
: High critical
Target Milestone: (C8)
Assignee: Alexander Köplinger [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2016-07-30 00:47 UTC by Oleg Demchenko
Modified: 2016-08-24 13:06 UTC (History)
9 users (show)

See Also:
Tags: C8Beta1
Is this bug a regression?: ---
Last known good build:


Attachments

Description Oleg Demchenko 2016-07-30 00:47:16 UTC
Steps to reproduce:
1) Clone this sample: https://github.com/onovotny/SampleXamFormsWithNetStandard
2) Run dotnet restore on for a PCL project
3) Run xbuild for a PCL project

Actual:
Compilation fails with - https://gist.github.com/olegoid/df182f74a458df4a77fc66657c5d4a53

Expected:
Successful compilation, msbuild build log - https://gist.github.com/olegoid/49e64ed87dec9ab8f6802991d854d7cd
Referenced sample runs fine with VS2015.

Env setup:
https://gist.github.com/olegoid/ad53441e7d887d27fbfd54658de0236b
Comment 1 Alexander Köplinger [MSFT] 2016-08-04 13:32:17 UTC
If I explicitly force ToolsVersion=14.0 by passing /tv:14.0 to the xbuild command line then it doesn't have that error (it fails with another seemingly unrelated compilation error).

Apparently the ResolveNuGetPackageAssets task doesn't get used when using ToolsVersion<14.0.

I'm digging into it.
Comment 2 Alexander Köplinger [MSFT] 2016-08-04 14:00:30 UTC
On Windows I get the same unrelated compile error about "App.xaml.cs(14,13): error CS0103: The name `InitializeComponent' does not exist in the current context". I guess I'm just missing some generation step for that as I'm building the project from the commandline.

What's interesting is that if I force /tv:12.0 on Windows, then the project *also* fails to compile with the same error as on xbuild because the ResolveNuGetPackageAssets task isn't used as well.

Given that the .csproj has ToolsVersion="12.0" it looks to me as if MSBuild14 just ignores that and builds with the latest ToolsVersion unless you force an explicit one via /tv.
Comment 3 Alexander Köplinger [MSFT] 2016-08-04 14:23:34 UTC
It seems this behavior is by design, according to https://msdn.microsoft.com/en-us/library/bb383796.aspx#Anchor_1

> Starting in Visual Studio 2013, the MSBuild Toolset version is the same
> as the Visual Studio version number. MSBuild defaults to this Toolset
> within Visual Studio and on the command line, regardless of the
> toolset version specified in project file.

Looks like we need to change xbuild to do the same.
Comment 4 Alexander Köplinger [MSFT] 2016-08-08 09:58:38 UTC
Fixed with https://github.com/mono/mono/pull/3363 in master and backported to C8 with 5110c098303da1eb8aa08ebad499facc3cc2f56b
Comment 6 Alexander Köplinger [MSFT] 2016-08-16 23:36:43 UTC
Sorry for the delay, I missed the Bugzilla notification.

I just tried again with "Mono JIT compiler version 4.6.0 (mono-4.6.0-branch/e571108 Thu Aug 11 19:06:39 EDT 2016)" and master and it does work fine for me. Not sure what's going on since the master build you showed in Environment Info show have the fix too...

@Atin can you please try reinstalling the latest C8 build and try again? Can someone else confirm/deny that it works?
Comment 7 Rodrigo Kumpera 2016-08-18 23:10:27 UTC
Moving to NEEDINFO based on the last comment.
Comment 8 Mohit Kheterpal 2016-08-19 18:17:27 UTC
@Rodrigo

I have followed the steps given in comment 0 and observed that I am still getting this issue with latest build of C8 I am using MonoFramework-MDK-4.6.0.161.macos10.xamarin.universal_f9a448b3f5069381fbe40c4bba44d545c6bc941d

Here is the output of my terminal : https://gist.github.com/Mohit-Kheterpal/02fbf085a707c5f2d84f5fda13703cb2

Please have a look and let me know, if I missed something here.

thanks
Comment 9 Oleg Demchenko 2016-08-19 18:20:23 UTC
Changing the status to reopened based on comment #8.
Comment 10 Alexander Köplinger [MSFT] 2016-08-24 09:24:06 UTC
I downloaded MonoFramework-MDK-4.6.0.161.macos10.xamarin.universal_f9a448b3f5069381fbe40c4bba44d545c6bc941d and it is fixed there as well according to my testing.

I think what went wrong in your case is that according to your terminal output "dotnet restore" threw an exception, but we need this otherwise the nuget packages wouldn't be restored. Make sure you followed the instructions on https://www.microsoft.com/net/core#macos.

Steps that worked for me:

1. git clone https://github.com/onovotny/SampleXamFormsWithNetStandard
2. cd SampleXamFormsWithNetStandard/XamFormsSample/XamFormsSample
3. dotnet restore
4. xbuild XamFormsSample.csproj

This should now print two errors about "The name `InitializeComponent' does not exist in the current context", that is fine. If you still see the "predefined type ... is not defined or imported" error then something went wrong.

I'm marking this as resolved again based on my observations :)
Comment 11 Sachin Saini 2016-08-24 13:03:27 UTC
I have checked this issue on latest cycle8 builds (MonoFramework-MDK-4.6.0.165.macos10.xamarin.universal_23c6a4d451ef47c67f1af6a475486300143fc19e) following by the steps given in comment10 and getting same behavior describe in comment10.

Terminal output:- https://gist.github.com/sachins360/2459fec99886dae317beecb1ec137806
Environment info:- https://gist.github.com/sachins360/f8d2faaf04694cd9b958d02b839eb1aa

Hence,I am verifying this issue.

Unable to change the bug status as this also disable for me.


Thanks!

Note You need to log in before you can comment on or make changes to this bug.