I’ve problem with publishing my ASP.NET Core web app to linux - problem with reference to Elements project.
If I add Elements project to ASP.NET Core as built dll, its generated to WebApplication.deps.json.
If Iadd it as project reference it does not happen.
I paste you test case.
WebApplication3 with reference to built ClassLibrary4
TestASPNETCore\WebApplication3\bin\Release\netcoreapp3.1\publish\WebApplication3.deps.json
There is a link to ClassLibrary4.
WebApplication2 with reference to project ClassLibrary4
TestASPNETCore\WebApplication2\bin\Release\netcoreapp3.1\publish\WebApplication2.deps.json
It’s the only difference between WebApplication2 and WebApplication3.
WebApplication3 is starting on linux
WebApplication2 isn’t starting on linux, but the is a workaround - copy WebApplication3.deps.json as WebApplication2.deps.json and it works.
I’ve also added ClassLibrary2 - c# library, and modified Elements library project file to be similar but it doesn’t change anyting.
Please help - I don’t want to build ma classlib seperately
In ASP.NET Core Elements project I can onlu publish as Azure WebJob - I want to publish it to local folder - maybe it’s possible but don’t know how
It’s the difference - ClassLibrary4 in deps file. When running it with IIS it generates it ok, and this generated deps file for IIS pasted for linux service works fine
Hello Mateus,
could you please retest this issue with latest build? Recently we added some fixes that could affect and fix this issue as well. I cannot reproduce it here now. I tried to rebuild the attached project with VS2022, and I can see ClassLibrary4 in the WebApplication2.deps.json. This part looks like this:
…
“targets”: {
“.NETCoreApp,Version=v3.1”: {
“WebApplication2/1.0.0”: {
“dependencies”: {
“ClassLibrary2”: “1.0.0”,
“ClassLibrary4”: “1.0.0”,
…
This should be fixed (post .2689), pending some more retesting on our side.
I’ve uploaded a new build for you to Personal Downloads, RemObjects Elements with Water - 11.0.0.2690.exe — please let me know if that one fixes the issue for you, as well.
Now it works - running under Linux, but still small diff - when published with built reference version of my dll is 1.0.0.1, when published with project reference version is 1.0.0
Looking into AssemblyInfo.pas I’ve got [assembly: AssemblyVersion(‘1.0.0.1’)]
Hello Mateusz,
I checked the json file and I can see that both ClassLibrary2 and ClassLibrary4 are contained there with 1.0.0 version as:
“ClassLibrary2”: “1.0.0”,
“ClassLibrary4”: “1.0.0”,
While both are declared as 1.0.0.1 in the AssembplyInfo file. So most probably it is not our problem, but some feature of Microsoft C#.
Okay. But if our .dll via project reference generates the same as as a VC# done does via project reference, then that’s “as designed”, as far as we are concerned. And even if it’s not, that’s Microsoft’s bug, as no art of our toolchain is involved in that part, for the VC# .dll (and most likely not for ours, either)…