mirror of
https://github.com/quamotion/dotnet-packaging.git
synced 2026-02-14 13:45:53 +00:00
Dotnet deb command does not read Visual Studio FolderProfile #115
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jb0490 on GitHub (Feb 4, 2022).
Our client/server solution produces a windows UWP client app and a server console web app. The server console app project target framework is netcoreapp3.1 and the runtime identifier is win-x86. This allows us to build the solution which creates a windows client app and a windows server console app.
To deploy the server console app to linux, we use use a build target in our solution's build project file that executes "dotnet publish" specifying "linux-x64" as the runtime target. This works fine. Now we wish to create a debian installer for this published folder and we found Packaging.Targets nuget package can do this. We have installed the NuGet package in our console server exe project.
However, there is a problem. This nuget package requires that the exe project contain the target runtime (i.e. linux-x64). Which is currently set to "win-x86". Attempting to run "dotnet deb" command without changing the runtime identifier fails with exception: "Assets file 'Console.App\obj\project.assets.json' doesn't have a target for 'netcoreapp3.1/linux-x64'. Changing the runtime identifier in the console app project file from "win-x86" to "linux-x64" saving the project then running the dotnet deb command results in the same assets file exceptions for the server console app dependent projects. Changing the runtime identifier in all the dependent projects from "win-x86" to "linux-x64" and re-running the "dotnet deb" command now produces a debian installer package. We've tested the debian installer and it works fine.
It is my understanding that Visual Studio exe projects can have only one runtime identifier. I have seen forum articles that show multiple runtime identifiers separated by semi-colon but this generates an exception for us (The "HasTrailingSlash" function only accepts a scalar value, buy its argument "$(OutputPath)" evaluates to "bin\Debug\netcoreapp3.1\win-x86; linux-x64\ which is not a scalar value). Interestingly, when we run our publish target that invokes "dotnet publish" the file "project.assets.json" for the console app project is updated replacing the target for ".NETCoreApp,Version=v3.1/win-x86" with ".NETCoreApp,Version=v3.1/linux-x64". However, it reverts back to "win-x86" when running command "dotnet deb".
In an attempt to resolve the multiple runtime identifier problem I created a FolderPublish profile to deploy the console app to Linux. The file FolderPublish.pubxml contains a PropertyGroup element with TargetFramework and RuntimeIdentifier properties just like the console app project. This allows defining separate RuntimeIdentifire properties for building the app and publishing the app. However, it seems the Packaing.Targets nuget package only reads the project file, it does not read the FolderPublish profile.
So we are stuck with two problems:
Is there anything we can do to not have to edit our projects post build and still be able to create a debian package?
@jb0490 commented on GitHub (Feb 9, 2022):
I found a solution to our problem. My understanding about Visual Studio projects having only one runtime identifier was incorrect. I incorrectly applied multiple runtime identifiers separated by semicolon to the wrong property name. I should have used the property RuntimeIdentifiers which is plural. Using the singular version of it generated the exception I mentioned above. We still need to have the RuntimeIdentifiers property defined in all our dependent projects but that is necessary since those dependent assemblies are included in our self-contained published folder.