Elements library in ASP.NET Core WebAplications - problem with publish (deps.json)

Hi,

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

Strange. Since the host project is VC#, I’m assuming it’s an issue with how MSBuild passes the reference, for project vs. hardcoded .dll reference…

Does this work ok if the host project is Elements (Oxygene or C#, doesn’t matter), too?

Indeed it seems .deps file for App2 is missing ClassLIbrary4, while App3 has it:

Logged as bugs://E25389.

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

Okay. thats something to look art separately, later )maybe start a separate thread).

But is the library in the .deps.jsob ok? That should be verifiable regardless of publishing.

Yeah, we’ll need to fid out why its missing ion the Project Reference case. The prpoblem tis probably on the MSBuild side…

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”,

Best regards.

I’ve installed VS 2022 and new version of Elements and it’s ok during build, but not during publish :frowning:
And it is the same in VS 2019

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’)]

Is that wrong/truncated version in the actual .dll, or in the .json file?

In the json file - it’s ok in dll

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#.

If I change project reference to dll reference it is 1.0.0.1 in deps.json

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)…

Is this causing any actual problems?

Not, It’s not causing any problems and it’s good information :wink:

1 Like

bugs://E25389 was closed as fixed.