How to deploy LOB app with legacy DLLs that depend on specific SxS MSVCRT?
How do I interpret this result and how do I deploy my 3rd party DLL with my LOB (Its not published in the store)?
I tried to include the MSVC*.dlls and MFC90.dll (with manifests) in my packages root folder. I then load the dll using LoadPackagedLibrary. That works on some machines, but on some it displays an error message that the Visual Studio Runtime has been initialized incorrectly.
Notice that this is not a security feature: it's an helper which will try (as much as possible) to discourage the practice of not using a manifest to load the crt dll.
However in Modern Apps, especially ones that are hosted in wwahost.exe, you have no influence of the manifest of the process nor its activation context (which I think is the culprit here). Both conditions checked by the _check_manifest function. So whatever I tried my 3rd party DLL could not load the msvcr80.dll (in the apps deployment root folder) properly.
// in pgort80.dll is ignored.
and it then returns TRUE from the check routine.
So all I had to do now was to create 2 dummy DLLs with no code, nor entry point (clocking in at 2560 bytes) named "mscoree.dll" and "pgort80.dll", load them into my apps process by using LoadPackagedLibrary and msvcr80.dll finally successfully loaded as a dependency of my 3rd party DLL.
I think my hack is worthy to be mentioned in "The Old New Thing" one day, but since MSFT takes care of backward-compatibility I can safely assume that this solution will run stable until MSFT comes to senses and supports such scenarios out of the box for LOB apps in the future.
Thanks everyone who tried to help to solve this issue!
You need to use libraries which are valid for Windows Store apps.
To use legacy libraries in a side-loaded app check out brokered Windows Runtime Components.
nah, I had this setup working just well. No brokered Runtime Components needed. Why make things so complicated.
I just deployed the legacy DLLs with my app, loaded them via LoadPackagedLibrary and they just worked, despite them using a lot of "restricted" API calls. Of course for file system operations I need to feed them special paths they have access too. No problem so far.
It all just works, because Windows does not do runtime checks of called API. So the legacy DLLs are even able to open sound input streams using the Winmm library. Of course I have to give them permission via the app first, so that level the APIs are protected.
Now on some customer devices I am getting a "C Runtime Error R6034" http://msdn.microsoft.com/en-us/library/ms235560(v=vs.90).aspx and on all my machines (none of them have VS installed, its plain win8.1 Pro) all just works fine. Any idea what could cause this?
You're in an unsupported deployment. I can't explain why this works or doesn't work, but my guess would be that somebody else installed the files.
My guess would be that on the machines where it works, somehow the 3rd party DLL is able to find the requisite 90 CRT DLLs from somewhere else on the system (like a centrally installed location).
Is it not possible for you to get the sources of the 3rd party DLL and rebuild it using the new VS?
The package dependency graph of the process. This is the application's package plus any dependencies specified as<PackageDependency> in the <Dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.
How is this done exactly?
Copying the correct DLLs from my machines SxS folder to the apps bin root does indeed allow to load the legacy Dlls on some PCs but it crashes on some machines with an "Internal Runtime Error". I wonder why that is? Those DLLs should be able to exist in memory side by side just fine. I compiled a quick normal VS Win32 project and its using the SxS from the Windows folders and everything runs just fine.
MSFT knows that this situation is unacceptable for LOB apps that are not deployed via the store? With Windows 10 more directed to Business customers does MSFT plan to revise its strategy and help us to convert legacy apps over to Modern Apps?
This situation with the runtime dlls restrictions makes it nearly impossible right now. We have systems where this setup works just fine, others pop up that weird R6034 error.
The WinRT does not support the usage of older versions of the C++ Runtime DLLs. I guess in some cases it works due to specific device drivers being present or something like that. Overall however it is not supported and likely won't be.
The Microsoft solution for the issue of legacy DLLs in LOB Apps are Brokered Windows Runtime Components that still live in the Win32 world as Rob already said. If you want WinRT only you will have to recompile those DLLs against a current version of the VC Runtime DLLs.
Of course you could also go the route of simply building a regular Win32 App and perhaps styling it's UI to be Touch Friendly (basically the way Adobe went with Photoshop).
I obviously don't know yet what Win 10 will bring on the API front but I'm rather certain that not all Win32 calls will become available to WinRT Apps.
Oliver, I am certainly not asking for more WinRT Win32 calls. I am asking to support the scenario where you just can't recompile old code with the new runtime DLLs. On the desktop loading apps that uses different versions of the VS runtime DLLs is perfectly supported. Why was this crippled in WinRT apps. It makes no sense. Especially in a controlled LOB deployment scenario.
Also I cannot use Brokered Runtime Components, since I am in the C++ field.
I tried to create a proxy using the VSIX for Brokered components MSFT provides.
I guess those are unsupported types then in Brokered components? How would one expose async operations to the proxy then?
Now there seems to be a difference how VS deploys apps and when I am installing the app via the packaged .PS file. Anyone know what's the difference?
It seems that apps deployed from inside Visual Studio behave differently to the ones I install on the device itself using the packages PowerShell script.
What exactly is the difference? Does VS register 3rd party dlls differently?
What exactly do you mean that it behaves differently, and why does it matter if it does?
It matters because I am still struggling deploying 3rd party DLLs in an LOB scenario. I tried the Brokered Component approach and it does only work if I deploy the package via VS. If I install the same package via PS script on the target machine it fails to properly load my 3rd party DLLs that is depended on an older MSVCR80.DLL.
And don't mention again that this scenario is not supported. I get it, that MSFT makes it especially hard to convert old desktop applications to the new platform, for whatever reason. Fact is it works when deployed via VS. So I wonder what does VS different than the installer script.
While VS can update an already deployed package in no-time (it seems to use a bin-diff algo to transfer only changed blocks from the package), the .ps1 script always reinstalls the app which takes much longer.
I think you've asked about this same scenario a number of times with answers that you're not satisfied with. If that's the case, it might be better if you open a support case and let us dig into this.
Still it would be nice VS would not deploy differently to manual installing a package. Overall, the whole deployment of LOB apps is still a mess. I hope MSFT fixes this with Windows 10.