Skip to content

Fix XM Full netstandard to copy in correct assemblies - #2685

Merged
chamons merged 4 commits into
dotnet:masterfrom
chamons:netstandard_xmfull_fix
Sep 19, 2017
Merged

Fix XM Full netstandard to copy in correct assemblies#2685
chamons merged 4 commits into
dotnet:masterfrom
chamons:netstandard_xmfull_fix

Conversation

@chamons

@chamons chamons commented Sep 13, 2017

Copy link
Copy Markdown
Contributor
  • Applications will build but crash on launch otherwise

- Applications will build but crash on launch otherwise
@chamons

chamons commented Sep 13, 2017

Copy link
Copy Markdown
Contributor Author

I caught this while writing an auto test.

Inputs="$(TargetDir)$(TargetFileName)"
Outputs="$(_AppBundlePath)Contents\MacOS\$(_AppBundleName)">
<ItemGroup>
<ReferencesOnly Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.Extension)' == '.dll'" />

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe name like ReferenceCopyLocalAssemblyPaths?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't that just append to the existing item group of that name?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, woops, the existing name doesn't have the word Assembly in it. n/m :)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I just wanted to make it easy to see where that extracted item was sourced from!

@radical

radical commented Sep 13, 2017

Copy link
Copy Markdown
Member

and a commit message like:

[msbuild] Fix XM Full netstandard to copy in correct assemblies

nuget packages can have `ref` (reference assemblies) and `lib` (implementation assemblies),
with the former meant for use with the compiler and the latter required for execution.

The `ResolveAssemblyReference` task populates `@(ReferencePath)` with the assemblies meant
for use with the compiler, so these get the `ref` assemblies. And it populates `@(ReferenceCopyLocalPaths)`
with any assemblies or files related (.pdb/.mdb/.xml etc) to the references, and this one gets the `lib`
assemblies.

XM needs to bundle the assemblies required for execution, but it uses `@(ReferencePath)` and thus
ends up with the reference assembly, which would fail to load at runtime! Instead, we extract the `.dll`
files from `@(ReferenceCopyLocalPaths)` and use that. 

@chamons

chamons commented Sep 13, 2017

Copy link
Copy Markdown
Contributor Author

I'll steal that when i squash merge.

@chamons chamons added the run-mmp-tests Run the mmp tests label Sep 13, 2017
@chamons

chamons commented Sep 13, 2017

Copy link
Copy Markdown
Contributor Author

build

@monojenkins

Copy link
Copy Markdown
Contributor

Build failure

@monojenkins

Copy link
Copy Markdown
Contributor

Build failure

@chamons chamons added the do-not-merge Do not merge this pull request label Sep 14, 2017
@chamons

chamons commented Sep 14, 2017

Copy link
Copy Markdown
Contributor Author

Looks like the breakages are non-trivial, will have to dig into them.

@chamons chamons removed the do-not-merge Do not merge this pull request label Sep 14, 2017
@chamons

chamons commented Sep 14, 2017

Copy link
Copy Markdown
Contributor Author

Ok, that fixes all tests locally and them when I hack it to run msbuild (https://gist.github.com/chamons/8fb988deb4daca052663efa116cea084).

I think the change is safe to stew in master, but i'm questioning 15.4...

@monojenkins

Copy link
Copy Markdown
Contributor

Build failure

@chamons

chamons commented Sep 15, 2017

Copy link
Copy Markdown
Contributor Author

This is strange, I can build things just fine locally, even with no XM installed. Let's try one more time to verify before I start digging up the world...

@chamons

chamons commented Sep 15, 2017

Copy link
Copy Markdown
Contributor Author

build

@monojenkins

Copy link
Copy Markdown
Contributor

Build failure

@chamons chamons added the do-not-merge Do not merge this pull request label Sep 18, 2017
@chamons

chamons commented Sep 18, 2017

Copy link
Copy Markdown
Contributor Author

Ok, somehow this broke build machine builds but not my local builds.

Digging...

@chamons

chamons commented Sep 18, 2017

Copy link
Copy Markdown
Contributor Author

I can reproduce if I git clean external/guiunit

@chamons
chamons requested a review from emaf as a code owner September 19, 2017 17:20
@monojenkins

Copy link
Copy Markdown
Contributor

Build failure

@chamons

chamons commented Sep 19, 2017

Copy link
Copy Markdown
Contributor Author

Test failure is known - https://bugzilla.xamarin.com/show_bug.cgi?id=59277

@chamons chamons removed the do-not-merge Do not merge this pull request label Sep 19, 2017
@chamons

chamons commented Sep 19, 2017

Copy link
Copy Markdown
Contributor Author

I feel more confident landing this, as it is nearly identical to what XI does.

@chamons
chamons merged commit f79f2e4 into dotnet:master Sep 19, 2017
@chamons
chamons deleted the netstandard_xmfull_fix branch September 19, 2017 21:38
chamons added a commit that referenced this pull request Sep 21, 2017
…2731)

- https://bugzilla.xamarin.com/show_bug.cgi?id=59474
- The idea is to force Full and Modern to expand facades the same way. That way, we get the same, working behavior.
- f79f2e4 was not sufficient, even though it matched XI, because of the difference between XI (and Modern) and what Full was doing.
- Some context:

PR #2685

And that was problematic because it was expanding the netstandard facades from `Microsoft.NET.Build.Extensions`
in the `ImplicitlyExpandNETStandardFacades` target.
But we want to build against XM's bundled facades *only*. So we disable the ns facades completely
by setting `$(ImplicitlyExpandNETStandardFacades) = false`.

But now we are in the situation where a XM/Full project referencing a ns project might fail to build
because of a missing `netstandard.dll` reference! And this same case was fixed for XM/Modern projects in
#2643 . So, we enable the use of that for XM/Full projects too
through `Xamarin.Mac.msbuild.targets`.
chamons added a commit to chamons/xamarin-macios that referenced this pull request Sep 27, 2017
- Applications will build but crash on launch otherwise
chamons added a commit to chamons/xamarin-macios that referenced this pull request Sep 27, 2017
…otnet#2731)

- https://bugzilla.xamarin.com/show_bug.cgi?id=59474
- The idea is to force Full and Modern to expand facades the same way. That way, we get the same, working behavior.
- f79f2e4 was not sufficient, even though it matched XI, because of the difference between XI (and Modern) and what Full was doing.
- Some context:

PR dotnet#2685

And that was problematic because it was expanding the netstandard facades from `Microsoft.NET.Build.Extensions`
in the `ImplicitlyExpandNETStandardFacades` target.
But we want to build against XM's bundled facades *only*. So we disable the ns facades completely
by setting `$(ImplicitlyExpandNETStandardFacades) = false`.

But now we are in the situation where a XM/Full project referencing a ns project might fail to build
because of a missing `netstandard.dll` reference! And this same case was fixed for XM/Modern projects in
dotnet#2643 . So, we enable the use of that for XM/Full projects too
through `Xamarin.Mac.msbuild.targets`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

run-mmp-tests Run the mmp tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants