Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force the app to use the dll in Libraries even if they exist in the root folder #56

Closed
julienGrd opened this issue Aug 30, 2023 · 12 comments

Comments

@julienGrd
Copy link

Hello guys, i met a problem with your library when i deploy my new version re-packaged with it on the server of my clients.
I have a program which update all the files of my app, so with the new version he will copy all the dlls in the libraries sub folder

So when my program start after first update, it will have this files architecture
|Root
||||||Mydll1.dll//these are the old dll, they are not supposed to be here but the program which update don't delete existing files
||||||Mydll2.dll
||||||||Libraries
||||||||||||Mydll1.dll//these are the new dll
||||||||||||Mydll2.dll

I manage inside my app to clean the root directory when it start because these dll are no longer in the root

But it seem, when these dll are present in the root, it use it rather than take it in the libraries folder

so i have these two problems :

  • my app fail to start or crash on some code, because it will run with Mydll1.dll a the root, which is not updated because no longer at the root (for example if i add a class or a method inside Mydll1.dll, these update will exist in the dll in the libraries subfolder but not in the root, so the program will crash because the class or method not exist in the dll it load)
  • it will be impossible for it to delete Mydll1.dll at the root because this dll is loaded itself by the program (and not the one in the libraries subfolder)

So the question, is there is a way when my app start to force take the dll in the libraries folder even if they exist in the root ?

thanks !

@liesauer
Copy link
Member

for native dll

you can force the search path to whatever you want by using DllImport("Libraries/Mydll1.dll")

for managed dll

to be honest, i don't have a good idea either, since those dlls may be preloaded by the corehost before the app be inited.

but you can try this

  1. open the *.runtimeconfig.json with any text editor
  2. find the NetBeautyLibsDir config, the value is supposed to be something like this: .;./libraries, try moving . to the end and becomes ./libraries;.
  3. save the file and start the app

@julienGrd
Copy link
Author

In my case it was the managed dll, Your solution work perfectly, thanks for the help !

@julienGrd
Copy link
Author

I don't know why but since the last update, the solution provided not work anymore (when i put "NetBeautyLibsDir": "libraries;.", it load first the dll at the root because when i want to delete them it say it impossible because its in use).

can you check that ?

thanks !

@julienGrd julienGrd reopened this Sep 19, 2023
@liesauer
Copy link
Member

can you post a testcase so i can check on it? i made a test but it works as expected.

@julienGrd
Copy link
Author

you can reproduce it with this project https://github.com/julienGrd/BlazorAppTestNetBeautyWithPdb

  • publish the main project somewhere
  • copy the class Library dll/pdf, which are in the libraries folder, at the root (next to the main app)
  • run the app, this one is suppose to delete the class library present at the root at startup. The app failed with "access to the path is denied" => I consider this case as Normal, as i didn't change the runtimeconfig.json
  • I change the runtimeConfig to force to charge first the libraries folder like that : "NetBeautyLibsDir": "libraries;.",
  • i start again the project, it failed with the same error => this is not normal
  • to be sure i downgrade with the same project the version 2.1.3.3. I repeat the operations above, and this time it was working

@liesauer
Copy link
Member

i can confirm that it's a bug of 2.1.3.4+, no clue of why ManagedAssemblyResolver is not be invoked

@liesauer
Copy link
Member

you can use the v2.1.3.4 package, this version still works with the pdb moving fix.

@liesauer
Copy link
Member

i will leave this issue open until figuring out why it's broken.

@julienGrd
Copy link
Author

Hello ! Is there any progress on this ?

liesauer added a commit that referenced this issue Mar 2, 2024
@liesauer
Copy link
Member

liesauer commented Mar 2, 2024

sorry that did not respond in time, i am having the Lunar New Year holidays recently.

this issue has been fixed in v2.1.4.4.

  1. reference the latest version and add <BeautyNoRuntimeInfo>True</BeautyNoRuntimeInfo> to your csproj.
  <PropertyGroup>
    <BeautyNoRuntimeInfo>True</BeautyNoRuntimeInfo>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="nulastudio.NetBeauty" Version="2.1.4.4" />
  </ItemGroup>
  1. modify NetBeautyLibsDir into libraries;. in the runtimeconfig.json file.
  2. then the app wouldn't load the dll at the root first anymore.

@liesauer liesauer closed this as completed Mar 2, 2024
@julienGrd
Copy link
Author

perfect it work, thanks for your help !

@liesauer
Copy link
Member

liesauer commented Mar 5, 2024

that's good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants