-
Notifications
You must be signed in to change notification settings - Fork 631
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
Improved installation support for DICOM [Native*] libraries #14
Comments
I've noticed it also matters if the app in question is a web application versus a regular command line / desktop application (binaries are within the /bin folder for a web app, etc). I think in my old local copy I had modified the loader code so that I could pass in a path. I also had it do some extra logging around what was found so I could debug it in production. Also, at that time, I had the loader specifically choose to examine one DLL or the other based on the bitness of the current process. That allowed for easy deployments in x86 or x64 environments (or x64 but with the IIS app in 32-bit mode) without having to worry about anything. |
I was doing a WADO service and had trouble reading the DICOM codecs, the solution to this was, in the class "DicomTranscoder", method "LoadCodecs", change this line "Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)" by "Path.GetDirectoryName(new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath)", this solution work fine in any app(console/desktop/web) |
@maikel87 Thanks for your input! |
Also there is too many complaints about VC runtime, there is no direct instructions for devs to pre-install VC runtime (x86 or x64) |
Thinking about this, could we embed the x64 and x86 DLLs as resources in the dicom.dll assembly? At runtime, when they're first required (which may be never, depending on the app), fo-dicom checks the current process' bitness, extracts the x86 or x64 DLL and loads it. Also, to round out the reading... |
@IanYates I would argue that embedding the DLLs as resources would make the DICOM.dll unnecessarily big in those cases when image codecs are not requested. I have looked a little closer into this issue this morning. I created a unit test for the I am preparing a PR where the
This is basically what @maikel87 suggested, except that I am using This fix did the trick for the unit test. It would be really good if someone could also verify that it improves the situation for web projects. |
Fail-safer search for DICOM directory location. Connected to #14
One of the most recurring issues on the Google Groups forum is that the DICOM [Native*] (codec) libraries are not properly recognized when invoking the DICOM library.
I don't have any clear answers on what needs to be done (or even if something needs to be done), but I think it will be good for the user experience of fo-dicom if the usage of the DICOM [Native*] libraries would be more fail-safe.
Perhaps installation via the NuGet package can be improved? It is not entirely straightforward, but it is possible to have conditional installment of NuGet packages based on CPU architecture, see here for example.
Please share your thoughts on this.
The text was updated successfully, but these errors were encountered: