Improved installation support for DICOM [Native*] libraries about fo-dicom

[IanYates]

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.

[maikel87]

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)

[anders9ustafsson]

@maikel87 Thanks for your input!

[hdesouky]

Also there is too many complaints about VC runtime, there is no direct instructions for devs to pre-install VC runtime (x86 or x64)
I don't know if Nuget supports bundling x86 and x64 on the same package or we should have 2?

[IanYates]

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.
See here http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
One commenter asks about using this for libraries (like fo-DICOM). We just need to have the fo-DICOM methods that might call into those DLLs first make a call to some thread-safe init() function.

Also, to round out the reading...
http://stackoverflow.com/questions/9228423/how-to-use-an-dll-load-from-embed-resource
And
http://stackoverflow.com/questions/6893060/load-an-assembly-from-an-embedded-resource

[anders9ustafsson]

@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 DicomTranscoder.GetCodec method, and it is then clear that even in this simple unit test scenario native assembly loading fails. As @maikel87 hinted, the problem appears to lie in the use of Assembly.Location. Assembly.Location refers to the location from which the assembly is loaded, which may very well be a shadow-copy location (which is often the case for unit testing within Visual Studio or ASP.NET projects, if I am not mistaken). Assembly.CodeBase on the other hand refers to the original location of the assembly, which is really what the DicomTranscoder.LoadCodecs method should be looking for when the path argument is null.

I am preparing a PR where the path setting in LoadCodecs is changed to the following:

path = Path.GetDirectoryName(new Uri(Assembly.GetExecutingAssembly().EscapedCodeBase).LocalPath);

This is basically what @maikel87 suggested, except that I am using EscapedCodeBase instead of CodeBase, since the escaped version should be more fail-safe in the URI context.

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.