Produce reference assembly packages for everything that exists today in c:\Program Files(x86)\Reference Assemblies

[davidfowl]

It would be great to not require visual studio installs to compile for any of the framework defined in c:\Program Files(x86)\Reference Assemblies. We don't have to do all up front but we could start with the most popular ones (this includes all of the PCL profiles as well). It would make it possible to compile PCLs on mono without installing the xbuild-frameworks package. It would also make it possible to compile class libraries on linux targeting .NET Framework.

I would allow us to delete this entire class that I hate so much 😄 https://github.com/aspnet/dnx/blob/dev/src/Microsoft.Dnx.Runtime/FrameworkReferenceResolver.cs

[akoeplinger]

Yes +:100:, it would make dealing with all the different profiles a lot easier.

[ericstj]

It's something that could be done. It would require special care to not clash with the actual targeting packs when used in MSBuild-based projects.

[weshaggard]

Yes it does seem like something we should consider doing.

[richlander]

I ran into this today. It's a pretty odd scenario to try to build a project on OS X that supports dnxcore50 and dnx451 and have it fail due to the 451 dependency. It's definitely a scenario that we need to do better on.

[davidfowl]

We're going to get this for RTM? We need a way to make sure that NuGet actually can work for this scenario

/cc @yishaigalatzer

[ericstj]

/cc @cartermp

[cartermp]

We've spec'd out the work for this and plan on making it happen. Unfortunately PDB generation is a problem for NetFX and PCL reference assemblies on *nix targets, and we need to get that solved before we can continue.

[clairernovotny]

I'll add to this list that once the pattern is created, it'd be great to share with Xamarin so they can potentially publish targeting packs for their toolset. /cc @migueldeicaza

[cartermp]

Linking related issues: dotnet/corefx#6706 and dotnet/corefx#6707

[clairernovotny]

@cartermp is there anything the community can do to help this this? What needs to be done here?

[cartermp]

Looping in @NumberByColors since he's on point for PDB generation. David, could you explain the issue at a bit more depth (and potentially correct any errors I have in my understanding of the issue)?

My understanding of the problem is that we can't generate good cross-platform C# PDBs for .NET Core when multitargeting yet. So we could put targeting packs up on NuGet and teach the CLI where to look for the reference assemblies, but you won't be able to debug anything. We've decided to put this on hold until we can get our debugging story for .NET Core in place.

As far as community help is concerned, I think it's worth evaluating how big of a blocker this is on your end. If you and other community members were okay with not being able to debug in the interim, perhaps opening up targeting packs as prerelease on a myget feed and teaching the CLI to understand them could be done. What are other folks' thoughts on this? @ericstj @richlander @NumberByColors @weshaggard

[clairernovotny]

I would say this -- I don't expect to debug other platforms with the .NET Core tools. My main scenario is using xproj to cross compile and then using a csproj->xproj ref to execute a platform-specific set of unit tests. I would use the .NET Core debugger to debug the netstandardapp output of a test project that references the xproj.

Getting a NuGet package out of the xproj is a nice plus too.

[NumberByColors]

Current plan (as of today) is to generate Portable PDBs by default for all .NET Core projects on all OSs, and continue to generate full PDBs for .NET Framework and PCL projects in VS on Windows.

We'd been ignoring the scenarios mentioned in this issue -- .NET Framework app and PCL compilation on OS X and Linux. If they're in scope, then our only choice is to generate Portable PDBs for these project types, because the mechanism for generating full PDBs isn't being ported to UNIX.

The implications of generating Portable PDBs for .NET Framework apps and PCLs remain a little unclear to me...if these PDBs never leave the machine on which they're generated, then I think we're good. But if these Portable PDBs are sent to a consumer of these .NET FX apps or PCLs, we'll have problems because these consumers will likely be on versions of VS on Windows that don't support Portable PDBs.

PDBs aren't usually included in NuGet packages, and symbol servers don't support Portable PDBs yet, so for the moment, I don't see the harm in generating Portable PDBs on OS X and Linux for .NET Framework apps and PCLs.

I don't fully understand all of the requirements around the issue, so I'm hesitant to give a hard recommendation.

[weshaggard]

@davidfowl did you close this because it is tracked somewhere else or did you give up on the idea?

[davidfowl]

Closing old bugs without activity. If deemed important, I'm refilling the exact same bug to push it to the top of the queue. This one didn't seem worth it.