Use shproj for shared code

[chcosta]

Currently, there's just one task in the repo, as this grows, we will likely need to begin sharing code between packages. When that occurs, we should consider using an shproj to share code rather than manual linking.

There is some discussion around support for using shared projects.

jaredpar 21 hours ago Why do all the manual likning here vs. creating a shared source project?

natemcmaster 21 hours ago Is shproj compatible with dotnet-CLI now?

chcosta 21 hours ago At the moment, this isn't even needed, these could just be moved into the only build project in the repo. I'll do that for now.

tmat 21 hours ago Is shproj compatible with dotnet-CLI now? Were there any issues? We use shared projects in Roslyn.

natemcmaster 20 hours ago Last I checked, $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\ doesn't exist in the msbuild that ships in .NET Core CLI

tmat commented 20 hours ago @natemcmaster Microsoft.CodeSharing.*.targets don't seem to do anything useful for the build. They are just setting project capabilities and such, presumably for design-time build in VS. Since they are imported conditionally it should work without them. @nguerrera @davkean Do shared projects work in VS Code/VS Mac?

jaredpar 3 hours ago Unsure about that particular MSBuild mechanism but we definitely use shared source projects in Roslyn + dotnet/CLI to build them.

[mmitche]

@markwilkie Any idea what the status of this is?

[natemcmaster]

cc @ryanbrandenburg - this is relevant to the .Sources stuff in aspnet/Extensions.

[ryanbrandenburg]

Yeah, I brought it up :)

[markwilkie]

The status is that this was not a priority - until this thread of course.... The first thing is to come up with what we think should happen. Then we can go about finding out the best way to fund it....

[tmat]

I'm not sure what the actual issue is. As @jaredpar pointed out we use shared projects in Roslyn and we have seen no issues.

[natemcmaster]

The problem is basically that you can't use .shproj to represent a package of shared source. ASP.NET and others, like the System.Text.Json team, want to produce 'shared source' NuGet packages which only contain C# in contentFiles/cs/any/.

The reason you can't do this boils down to 2 limitations in MSBuild.

1. Solution files don't actually build .shproj files. Here's an example .sln file that only has a .shproj in it. As you'll see, this project does not appear in the section GlobalSection(ProjectConfigurationPlatforms) which defines the list of projects that actually compile.

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.26124.0
MinimumVisualStudioVersion = 15.0.26124.0
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "SharedProject1", "SharedProject1\SharedProject1.shproj", "{048A3DB6-363C-4CCA-A4B5-CDF3DDDD896C}"
EndProject
Global
	GlobalSection(SharedMSBuildProjectFiles) = preSolution
		SharedProject1\SharedProject1.projitems*{048a3db6-363c-4cca-a4b5-cdf3dddd896c}*SharedItemsImports = 13
	EndGlobalSection
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Any CPU = Debug|Any CPU
		Release|Any CPU = Release|Any CPU
	EndGlobalSection
	GlobalSection(SolutionProperties) = preSolution
		HideSolutionNode = FALSE
	EndGlobalSection
	GlobalSection(ExtensibilityGlobals) = postSolution
		SolutionGuid = {83C46E69-85C3-4C0A-91D1-ECF6191F9673}
	EndGlobalSection
EndGlobal

2. dotnet msbuild MyProj.shproj doesn't work.

PS > dotnet msbuild .\SharedProject1\SharedProject1.shproj
Microsoft (R) Build Engine version 15.9.19+g938f3292a0 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

C:\tmp\shpr\SharedProject1\SharedProject1.shproj(8,3): error MSB4019: The imported project "C:\Users\namc\.dotnet\x64\sdk\3.0.100-preview-009750\Microsoft\VisualStudio\v15.0\CodeSharing\Microsoft.CodeSharing.Common.Default.props" was not found. Confirm that the path in the <Import> declaration
is correct, and that the file exists on disk.

[natemcmaster]

Two ideas for working around this:

1. Create a dummy ‘.csproj’ file for each shared sources package. This dummy project needs to strip out the C# compiler targets since it shouldn't make an assembly. This is basically what we did in KoreBuild. AFAIK it’s the only way to get Visual Studio, dotnet.exe, and NuGet's packing targets to play nice. Projects in the same repo then need to add <Compile> item groups to point to the folders of code they need as <ProjectReference> won't work.
2. Change aspnet/Extensions to build a list of projects, not a .sln file, and implement some targets for .shproj files which don't require full MSBuild. This one is probably the more expensive option, but I think would lead to a nice project convention for shared sources.

[tmat]

We did [1], but we keep the assembly building. See e.g.: https://github.com/dotnet/roslyn/tree/master/src/Dependencies/PooledObjects

The reason why you might want to build the assembly is to validate that the source files can be built against given TFM. For example, we want the source files to be buildable in projects that target netstandard1.3.

This is a targets file that these packages include: https://github.com/dotnet/roslyn/blob/master/eng/targets/SourcePackage.targets

Other than setting some properties to tweak the build, we also generate Source Link information that is included in the NuGet package, so that the sources can be debugged. I want to move this logic to Source Link package at some point. Haven't had time to do so yet.