Error publishing simple DLL on .NET Core 3.1

[supermartzin]

Steps to reproduce:

• Create simple Class library project targeted for .NET Core 3.1
• Add the latest DllExport package via NuGet (configure via Basic project integration stuck on adding property message #175 at the time of writing this)
• Build the project (successful)
• Try to publish the project for either combination of platforms and you get the error

---

• DllExport version: v1.7.3.58831+9a4bc51
• Used Visual Studio 2019 v16.8.2
• Target platform: x86
• Runtime identifier: win-x86

Information from VS Output log:

Build started...
1>------ Build started: Project: DllExportTest, Configuration: Release x86 ------
1>DllExportTest -> [...]\DllExportTest\bin\x86\Release\netcoreapp3.1\win-x86\DllExportTest.dll
2>------ Publish started: Project: DllExportTest, Configuration: Release x86 ------
2>Determining projects to restore...
2>Restored [...]\DllExportTest\DllExportTest.csproj (in 291 ms).
2>DllExportTest -> [...]\DllExportTest\bin\x86\Release\netcoreapp3.1\win-x86\DllExportTest.dll
2>The file '[...]\DllExportTest\bin\x86\Release\netcoreapp3.1\win-x86\DllExportTest.pdb' to be packed was not found on disk.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========

Project builds without any issue but publish fails every time, tried also changing parameters with no luck.

Demo Project files:
DllExportTest.zip

Thanks for help! ✌

[3F]

Thanks for the report!

Temporarily try the following (netstandard & netcoreapp targets only)

    <DebugType>embedded</DebugType>
    <DebugSymbols>true</DebugSymbols>

or

    <DebugType>none</DebugType>
    <DebugSymbols>false</DebugSymbols>

or related settings in project properties using VS IDE

[supermartzin]

Thanks for the temp solution, seems that if you set DebugSymbols to true, you don't need to specify the DebugType element.
On the other hand, when DebugSymbols are set to false or not present, you have to specify the DebugType.

Now the publishing works, but even with library OutputType, I keep getting .nupkg file as a result of publishing instead of .dll file and all the references. But I suspect that's another problem not related to this.

[3F]

Make sure CopyLocalLockFileAssemblies property is not a true.

If only some specific, then below:

Element	attr/tag=value
PackageReference	ExcludeAssets="runtime" (ie. only at build time)
ProjectReference	Private="False"
Reference	Private="False"

To disable generation of the NuGet packages try the following below;

When Publish

<IsPackable>False</IsPackable>

When Build

<GeneratePackageOnBuild>False</GeneratePackageOnBuild>

You can also use https://github.com/3F/vsSolutionBuildEvent for other custom scripts (public/private) and much more besides or together with msbuild

[supermartzin]

IsPackable switch indeed disabled the generation of the NuGet package but now nothing gets published, not a single file :-/

[3F]

Unfortunately there is no unified solution at this day.

'embedded' for some reason or 'none' ... I don't want either implement some option for this case or forcefully remove pdb
Because first of all we need to review this issue 3F/coreclr#3

Keep it open for the future fixes!

I remind everyone,

• This affects only .NET Core based projects.
• Temp solution is Error publishing simple DLL on .NET Core 3.1 #176 (comment)

Thanks

[3F]

IsPackable switch indeed disabled the generation of the NuGet package but now nothing gets published, not a single file :-/

Strange, it must generate a modified assembly. This however is another issue. Please open it as question if you want to discuss some solution.

[cabbytech]

I had similar problem. Winforms targeting 3.1 Single File option would not publish but would with Single File un checked.
Tried the solution

<DebugType>embedded</DebugType>
<DebugSymbols>true</DebugSymbols>

Resulted in whole project being unloaded! Coud not re-load until I removed the above.

[3F]

Resulted in whole project being unloaded! Coud not re-load until I removed the above.

@cabbytech msbuild properties must be declared into PropertyGroup nodes. Did you? You can simply add a new one into parent Project node or use any available.

Also I remind this can be configured inside Visual Studio IDE using project properties menu - Build - Advanced

[cabbytech]

Sorry my mistake. I have corrected. However, will not publish with that setting either.

[3F]

@cabbytech what error? or better to look log or .csproj file

make sure this was not redefined by other DebugType/DebugSymbols properties

[cabbytech]

Nothing of value in the log file but output window:

  System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath
  at Microsoft.NET.HostModel.Bundle.Bundler.GenerateBundle(IReadOnlyList`1 fileSpecs)

[3F]

@cabbytech It's unclear at all. Please use /v:diag or better /bl. Note the /bl by default collects the source text of project files. See Doc

[CodingMadness]

Is this closed by now?

[3F]

Okay, I finally looked into this issue.

Although I can't reproduce your problem for missing a .pdb,

2>The file '[...]\DllExportTest\bin\x86\Release\netcoreapp3.1\win-x86\DllExportTest.pdb' to be packed was not found on disk

56d4479 improves deletion via temp renaming.

However, this is not the general point of the current issue;

Found this in your FolderProfile.pubxml

<SelfContained>true</SelfContained>

Current project does not officially support publishing of the self-contained a platform-specific executable.

Also

<PublishSingleFile>True</PublishSingleFile>

You can use ILMerge (or similar) at Pre-Procesing stage to combine modules if you're looking option for a single file, moreover for libraries (because this option only for executable app as far as I remember it)

So I checked your DllExportTest.zip (thank you for the prepared example!) on VS 17.12.1 publishing is ok even for much older DllExport 1.7.3 (your configured project)

1>------ Build started: Project: DllExportTest, Configuration: Release x86 ------
Restored D:\prg\issues\DllExport\_github\176\DllExportTest\DllExportTest.csproj (in 28 ms).
1>DllExportTest -> D:\prg\issues\DllExport\_github\176\DllExportTest\bin\x86\Release\netcoreapp3.1\win-x86\DllExportTest.dll
2>------ Publish started: Project: DllExportTest, Configuration: Release x86 ------
2>DllExportTest -> D:\prg\issues\DllExport\_github\176\DllExportTest\bin\x86\Release\netcoreapp3.1\win-x86\DllExportTest.dll
2>DllExportTest -> D:\prg\issues\DllExport\_github\176\DllExportTest\bin\x86\Release\netcoreapp3.1\win-x86\publish\
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

But the publish will receive an original unmodified module that's different issue #235, but this is already fixed since 2a8d962
You can test related CI build until new release

tl;dr

• SelfContained=true is not a bug, we just do not support it.
• For a PublishSingleFile you can use DllExport's Pre-Procesing, for example, together with pre-configured ILMerge or something else.

I close the issue but please open it again if the solution above does not help. Thanks.