Repository navigation
Deliver CoreFx façades next to MSBuild.exe #1542
Description
We just encountered an intermittent failure fixed by dotnet/sdk#629 that occurred because façade assemblies are no longer available in the MSBuild.exe directory.
Prior to RC.3, the façade assemblies were available because Roslyn placed them next to its assemblies, which were in the MSBuild bin directory. After #1406 moved Roslyn to its own directory, the façades were no longer available to tasks that did not redistribute them (unless some other mechanism had loaded them already).
Since we expect it to be common to build a task assembly that depends on these façades, it would be nice if MSBuild itself distributed them so they're available to the loader for all tasks and the tasks don't have to each redistribute them.
Activity
jaredpar commentedon Jan 11, 2017
In addition to distributing the facades MSBuild should have some docs / be explicit about exactly which version of Desktop / Net Core it supports for a given version.
From an extensibility stand point I need to know what version of Net Standard I should target with my extension. For an extension targeting that version I should have no need to deploy facades as MSBuild should be providing them.
rainersigwald commentedon Jan 24, 2017
Talked about this with @jaredpar and @AndyGerlicher yesterday. The plan is:
MattGertz commentedon Jan 25, 2017
JoC would like you to talk to Eric St. John first.
dsplaisted commentedon Jan 25, 2017
I'd suggest getting @ericstj and @weshaggard's feedback on this. I think we made the statement yesterday that the facades are part of the platform and thus should be provided by MSBuild. I've realized that's not always true- we sometimes deliver facades in NuGet packages to make things work on versions of .NET that have already shipped. And if the facades really were part of the platform, then they should already be there and MSBuild shouldn't need to provide them.
I don't mean to imply that we shouldn't include the facades with MSBuild- it might be the right thing to do. But I think we should talk to the facade experts first.
jaredpar commentedon Jan 25, 2017
It's very common when targeting Net Standard, even when running on desktop, for an EXE to be required to deploy facades in order to successfully run. Today MSBuild is deploying only a minimal subset of the facades. That leaves every extension guessing which of the remaining faceds it should / shouldn't be deploying in order to run.
The most consistent story here is for MSBuild, which is an extensibility platform, to ship the full set of facades. Consider other extensibility environments like Visual Studio which had the same problem and came to the same conclusion.
ericstj commentedon Jan 25, 2017
I think that MSBuild should include the largest set of desktop facades that is available at the time it ships in order to enable folks to limit their redist dependencies from tasks. It's not tied to a "netstandard" version, the facades were talking about here are used for desktop, not netstandard. So I'd expect you to include the latest facades for whichever version of desktop you are targeting. The set should be at least MSBuild and its closure, probably all of NETStandard.Library and its closure. As Jared suggests you can go as far as pulling in every package we ship from CoreFx that supports desktop, I'm leaning this way myself. While we're at it, how about throwing in a version of JSON.Net and some other popular nuget packages? I'm only half-kidding here, dealing with dependencies in desktop MSBuild tasks is a pain.
To restate, we're only talking about desktop here, for netcore you get what's in the shared framework. I suppose if you wanted to bundle some additional assemblies next to your netcoreapp version of MSBuild you could, but its less interesting because the binding model for netcore is less rigid (no binding redirects).
If you're recommending folks publish a
netstandardproject as a raw dll and expecting that to work generically, it won't. Consider that there are plenty of fat packages out there and a library published fornetstandardwill be missing its TFM-specific assets.Finally in all these cases folks need to know what not to put in their packages because build/publish isn't going to do the right thing. Perhaps in v.Next you can make use of the trimming / conflict resolution we're putting in to model what's in your MSBuild "platform".
jaredpar commentedon Jan 25, 2017
@ericstj
MSBuild is both a desktop and CoreClr application. It now supports hosting task DLLs which are portable and target Net Standard. Why should they target desktop here?
Look at this from the other angle. I'm an MSBuild task author and I want to build a portable task. How can MSBuild communicate the set of facades that will be available to my task when run on either runtime? Anything not guaranteed to be available is a facade my task needs to bundle.
ericstj commentedon Jan 25, 2017
That's a requirement and something they should already doing for their EXE. There is no such thing as a portable layout for an exe. Consider that the System.Runtime.dll, etc for desktop are very different from the .NET core: you cannot have one application layout that works in both places. They need not target desktop, but they should already be publishing for it.
Yeah I understand that. MSBuild is free to go off and define their own set of assemblies they consider their platform: not just facades, but actual contracts (even 3rd party libraries as I previously suggested). That's a different pivot than desktop facades and its a discussion that looks more like "what's the set of API that MSBuild provides as a platform". I was trying to scope this thread because, presumably, NETCoreApp has already done a decent analysis here with shared framework and thats a superset of what MSBuild would want. Sure, MSBuild is free to be different, but then they cannot piggy-back on the shared-framework trimming that already exists.
Also, as I mentioned I don't think "portable" task is a thing, unless it has caveats. There is no runtime resolution of TFM specific assets. This is why apps must be TFM-specific as I mentioned above. So if you want to have a portable plugin model, you need to make sure the host app can provide any TFM-specific assets that your plugins might want to use. MSBuild sould consider this when determining what things to bundle.
It looks to me like @rainersigwald was suggesting that they merely document it. I think you might be able to use the features in https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/ResolvePublishAssemblies.cs to either list an MSBuild (meta-)package a platform package, or mark all the packages you want to be platform as private assets, but I haven't tried it. In v2 we'll have conflict resolution that supports a platform manifest, like I mentioned previously.
jaredpar commentedon Jan 25, 2017
@ericstj
Yes. But they can define the minimum set of facades / contracts that their EXE will bring with it on all platforms.
The future of .Net is portability but your saying we can't have a portable way to build applications?
Tasks are just DLLs. There is no reason I shouldn't be able to build a portable DLL and have MSBuild host it. Forcing me to build a different DLL for every platform that MSBuild supports doesn't make sense.
ericstj commentedon Jan 25, 2017
Sure, and they'll need different files for each platform if the component has a different implementation on that platform. Those different versions of the files can't live in the same path...
Like I said before, you can build a portable application today, but you need to publish a layout for each platform(TFM). This is because the apps dependencies have platform(TFM) specific implementations. Now fast-forward to NETStandard2.0 where we've asserted that a larger set of the platform is available and inbox in the platform and you can see how it will likely eliminate the need for any dependencies with platform(TFM) specific implementations. You'd still hit the same issue if took a dependency that needed a platform specific implementation app-local, but NETStandard2.0 aims to reduce the likelihood of that.
Again, I didn't say you needed to build a different dll. I said there's a caveat here that dependencies may be TFM specific and both need to be published. I agree with you that MSBuild should try to realize a portable plugin model by providing those TFM specific files. I'm saying that MSBuild can't present it as completely portable, since any dependency that's TFM specific and not in their provided set would require the plugin to publish that dependency separately. Now we could ask for MSbuild to define a convention for "fat" layouts that have TFM-specific assets side-by-side, but that feels like feature creep.
jeffkl commentedon Jan 25, 2017
@ericstj I'll need some more info on how to gather the facade assemblies so we can package them up. If I made a build project that targets
net46and depends onNETStandard.Library, does that give me the facades when I publish? Or is it more complex?ericstj commentedon Jan 25, 2017
@jeffkl that'll give you the set that's in NETStandard.Library and its closure. MSBuild may be depending on packages above NETStandard.Library and you'd want to include those as well.
If you have an entry point package, a package that represents MSBuild.Exe and its dependencies, just publish that for net46 and it'll give you all the facades needed for MSBuild to run. That's the first option I suggested. Now if you added a NETStandard.Library ref to that project (if you don't already have one) and publish it for net46 that'll give you all the facades needed to satisfy NETStandard.Library.
If you want to provide additional packages as a convenience for developers, as we've suggested, just add more references and publish for net46. I'm putting together a few samples to demonstrate, will share in a moment.
ericstj commentedon Jan 25, 2017
Here are some samples: https://gist.github.com/ericstj/af57217e1972f78408d66b4eed042093
jeffkl commentedon Jan 26, 2017
Thanks @ericstj I'll try and make progress on this today
33 remaining items
johnbucayan commentedon Nov 24, 2017
Hi everyone. I think this trail is already closed but my solution when I encounter this error is uninstall and re-install the typescript.exe and it works.
jeffkl commentedon May 11, 2018
I'm closing this since we've moved to .NETStandard2.0 and all facades are in later versions of the .NET Framework.