Open daxian-dbw opened 7 years ago
Quoted from an email from @eerhardt regarding this issue:
I spent some time investigating this scenario today. It looks like it currently isn’t possible with .NET Core 1.0 SDK that ships in VS 2017 RTM.
I tried doing this by setting
<CopyBuildOutputToOutputDirectory>false</CopyBuildOutputToOutputDirectory>
In the “metapackage” .csproj. But that leads to CSC compile errors.So then in the referencing projects I added:
<ProjectReference Include="..\metapackage \metapackage.csproj" ReferenceOutputAssembly="false" />
But then I hit a bug in the .NET Core SDK: #1020
I looked into the project.json
support for this. We had checks when compiling the application, packing, creating the .deps.json, and publishing that if a project didn't have any source files, we just skipped the assembly for that project.
See
I'm not sure if we should add similar logic to MSBuild (check for source files), or have a single master switch that says "Don't care about the assembly for this project".
i'd be interested to see a "proper" nuget project type - no built assemblies, maybe even no target frameworks - just references, maybe content (> msbuild props/targets files)
^ That would also be extremely useful for packaging native assets. (since nuspec + nuget pack
requires windows)
So is this an issue that belongs to dotnet/project-system?
@craigb - no this is the correct repo for this issue, IMO.
@livarcocc @nguerrera @dsplaisted - to take a look and triage
Can we get any progress in .Net Core 3.0?
Note, you can accomplish this in the project by setting the following properties:
<NoBuild>true</NoBuild>
<IncludeBuildOutput>false</IncludeBuildOutput>
<IncludeSymbols>false</IncludeSymbols>
Then you can just run the Pack
target on that project, which can be set to the default target at the top:
<Project Sdk="Microsoft.NET.Sdk" DefaultTargets="Pack">
Now when you call MSBuild on that project, it will pack the nuget package, but you won't get an empty assembly built or included in the package.
@eerhardt Thanks! I am not sure that <NoBuild>true</NoBuild>
will works for us because we use the meta csproj to build dependences.
Maybe ReferenceOutputAssembly="false" on all project references to meta project? I think that will keep it out of .deps. But not sure if it will break getting the transitive refs through it.
I can not compile with ReferenceOutputAssembly="false"
because this broke dependencies.
Current structure:
powershell-win-core.csproj -> Microsoft.PowerShell.SDK.csproj (meta project) - other csproj-s
Our goal is not to create a dll for Microsoft.PowerShell.SDK.csproj, but dependencies should work at the compilation stage like at Core 1.0 time. Is it possible?
I don't think it is possible. I think we probably would need to introduce a feature of some kind to support that.
@daxian-dbw Is still important for us to have the meta project since we moved on .Net Core 3.0 and could use other features to resolve dependencies and load assemblies?
When building with .Net 7, you can add these properties to your project to keep build output etc. out of your output and publish directories:
<GenerateDependencyFile>false</GenerateDependencyFile>
<CopyBuildOutputToOutputDirectory>false</CopyBuildOutputToOutputDirectory>
<CopyOutputSymbolsToOutputDirectory>false</CopyOutputSymbolsToOutputDirectory>
<CopyDocumentationFileToOutputDirectory>false</CopyDocumentationFileToOutputDirectory>
<CopyBuildOutputToPublishDirectory>false</CopyBuildOutputToPublishDirectory>
<CopyOutputSymbolsToPublishDirectory>false</CopyOutputSymbolsToPublishDirectory>
I found these properties in these files:
Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets
dotnet\sdk\7.0.304\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets
I have a .NET Core meta-package project defined in
project.json
. It contains no code but just references to a few other sub-projects and some packages. This meta-package project exists for 2 purposes:This works fine with
project.json
-- when building the meta-package project, all referenced sub-projects get built and the meta-package project itself doesn't produce anything. Now with .NET Core SDK 1.0, I'm migrating fromproject.json
to.csproj
viadotnet migrate
, and I find the behavior has changed -- building the meta-package project still get the referenced sub-projects built, but itself starts to produce an empty assembly.This causes an empty
meta-package.dll
to appear in the publish folder of the top-level project, and I cannot simply remove it with an after-build target because it's also recorded in the generated.deps.json
file, which makes it part of the TPA (trusted platform assemblies). So simply removing the empty assembly will cause the application to crash at startup.Note that I have set
<IncludeBuildOutput>false</IncludeBuildOutput>
in the meta-package project file. It does help to make the empty assembly not included in the NuGet package produced out of the meta-package project, but the empty assembly still gets produced, and that causes the empty assembly to be published and put in thedeps.json
file when building the top-level project.The
project.json
file and the corresponding.csproj
file are attached. It's part of the powershell core project, and you can see the whole project at https://github.com/PowerShell/PowerShell/tree/master/src. TheMicrosoft.PowerShell.SDK
meta-package project is referenced bypowershell-unix\project.json
,powershell-win-core\project.json
andpowershell-win-full\project.json
.project.json.txt Microsoft.PowerShell.SDK.csproj.txt
/cc: @eerhardt