2016R2 dependancies problem with 8.1

I tried to copy and run an x86 executable produced by 2016R2 to Windows 8.1.

I copied all the corresponding DLL in the x86 folder within extras/files next to the executable, but I get a Msgbox explaining that I need MSVCR100.DLL. Should it not be part of the DLL in x86 ?

Then I tried to install the vc_redist.x86.exe but at the end of the install process, Windows 8.1 reports an error :
The installation program failed because of one or several problems. Please correct these errors, then try again. For more information check the log.
0x80240017 unspecified error.

This is not very encouraging…

I do want to have HiDPI support, but if it becomes OS Russian Roulette, not sure I want the technical support burden…

https://dl.dropboxusercontent.com/u/17407375/install.log

You still need to include your Libs folder even if you are using the Universal Runtime DLLs instead of the redist.

The folders Libs and Resources are there, of course. But no trace of MSVCR100.DLL in the libs folder created by the build.

It could be that MSVCR100.DLL missing error is because of a plugin dependency, not Xojo itself. If so, you could just copy it in and include it with your app yourself. Current Xojo builds don’t include older VS DLLs.

This awkwardness is the reason why I still not updated to Xojo 2016r1 or higher for Windows apps.
I guess I will receive too many users complaining about ‘You program isn’t working anymore, I want my money back’. :slight_smile:

You know, this kind of thing is exactly what made me jump to RS a long time ago, when there where so many support requests for the absence or incompatibility of VB100.DLL.

The last thing I need is a flurry of support requests because it works sometimes, and sometimes not. In a first step I shall build with 2015R4.1, and forget 2016Rx.x when Windows is concerned.

DLL hell is back with a vengeance :confused:

For Windows I don’t see much of improvements since 2015R4.1 Too mutch open ends till now and some 3rd party controls just don’t work correctly since we have the hidpi option in 2016Rx, even if this option is switched of for legacy behavior.
For a running Windows project I even don’t have the option to go beyond 2015R4.1

The addition of MSVCR100.DLL is not a big issue I think, just include in the installscript which you should provide anyway. The hell of DLL was actually about COM. As I am informed well, we can have a version of MSVCR100.DL bound within our own package.

You might want to register your dll manually using

regsvr32 msvcr100.dll

in a cmd-window if not installed / registered automatically.

I had the same bug. My Innosetup-Script ran normal but after starting the app I got the same error. I use postgres with the MBS SQL Plugin and there are some dependencies.

This works for me:

Run vc_redist.x86.exe as administrator (right mouse click, Execute as Administrator). Confirm and your app should run…

[quote=280778:@Thomas Rottensteiner]You might want to register your dll manually using

regsvr32 msvcr100.dll

in a cmd-window if not installed / registered automatically.[/quote]

msvcr100.dll is a flat DLL. It cannot be registered with regsvr32. A flat DLL does not need to be registered. It only has to be available and found by the app.

[quote=280815:@Dagmar Schreeck-Oeser]I had the same bug. My Innosetup-Script ran normal but after starting the app I got the same error. I use postgres with the MBS SQL Plugin and there are some dependencies.

This works for me:

Run vc_redist.x86.exe as administrator (right mouse click, Execute as Administrator). Confirm and your app should run…[/quote]

msvcr100.dll is not part of vc_redist.x86.exe. Running vc_redist.x86.exe will not install it.

I also view this decision for Xojo 2016 and later to be a step backward into the old world of dependency hell. But then there is no choice when Xojo is developed using Visual Studio 2015 that stipulate this.

Unexpected things can happen, like unexplained situation on users’ computers for whatever reason this dependency cannot be installed or cannot be updated to work with the app. This can lead to support hell where the users can hound the support staffs for days and weeks. Looking at this forum, even Xojo developers are themselves also having this dependency problem or not knowing what is needed to be done.

I have for many years faced this problem with apps I wrote with VB6. So much so that I had to find a way to move away from the OCX, the ActiveX DLL. I did what I had to do in InstallShield to get the dependencies installed but there will always be some who will have dependency problem. That was when I decided to give Xojo another go.

Recent times, I have found a way to have my existing VB6 apps work with OCX and ActiveX DLL without registration by including a manifest in the complied exe. There are also now available non-reg versions of the common controls. So now come the time I have to decide whether to go Xojo or stay with VB6. I know support for VB6 have already ended but it is still a damm good platform. The biggest advantage I find is that Microsoft is commited to include the VB6 runtiime in all new Windows since Windows XP. Granted VB6 will forever be only 32-bit. But then Xojo at the moment is still 32-bit (64-bit will be beta for I don’t know how long more).

Perhaps Xojo can find a way to merge all the DLLs into only ONE DLL and make this ONE DLL available in the app folder during build and forget about the vc_redist.x86(64).exe. Then this dependency hell with be done with.

msvcr100 is likely a requirement from a plugin, not Xojo- include it with your app and you should be fine.

Microsoft strongly recommends the redist approach for the universal runtime since security and other bug fixes can then be made via Windows Update. In fact it wasn’t until the very end of their dev cycle that they even allowed the approach of including DLLs directly at all- since we and others really wanted to at least provide the option to our users.

I tried to copy my msvcr100.dll from 64bit Pro to 32 bit Windows 8. It does not work.

Now chasing the proper msvcr100.dll for each Windows version. Hell, hell, hell.

And since we cannot distribute full blown 64-bit stuff at the moment, we can’t state that our clients should have at least 64-bit versions of Windows.

Yoiu know what airco-systems and this OS have in comon ?

Once you open a window, it doesn’t work anymore.

I did check – a plain hello world does not require it, so it must be one of the MBS plugins I use that requires it.

That said, it is VB100.DLL all over again. Xojo is not the only one suffering from that plague :
https://social.msdn.microsoft.com/Search/en-US?query=msvcr100.dll%20missing&pgArea=header&emptyWatermark=true&ac=3

My current app is too far developped with 2016R2 to go back to 2015R4.1 without major overhaul, not mentioning the fact that I would stop having common code between Mac and Windows. So I will have to swallow the pill somehow. But I swear next app will be developed for Windows with 2015R4.1. Given the very few PC 4K today I can live a long time without HiDPI support. 2015R4.1 will become Xojo’s VB6.

When I think I went RS because of VB DLL mess…

MSVCR100.DLL appears to be part of the Visual C++ 2010 Runtime

https://social.technet.microsoft.com/forums/windows/en-US/52f0bd37-9a08-41b6-bb43-fa01ef3ebc4a/msvcr100dll-is-missing

I do use two different plugins : MBS plugins, and Formatted Text Control with BKSSpellCheckerDemo.xojo_plugin TextInputCanvas. Now I’ll have to find out which one requires that pesky critter.

Christian ? Do you still have C++ 2010 runtime calls ?

I wait using Xojo 2016r2 for Windows apps until all Windows users are upgrade to Windows 10 :slight_smile:

[quote=280874:@Michel Bujardet]I tried to copy my msvcr100.dll from 64bit Pro to 32 bit Windows 8. It does not work.

Now chasing the proper msvcr100.dll for each Windows version. Hell, hell, hell.[/quote]

In the normal practice, the plug-in developers should be providing you all the dependencies to go with our apps - 32-bit dependencies for 32-bit app and 64-bit dependencies for 64-bit app. And in their help documentation, they should provide the instruction clearly. So normally, if they do that then you will never be in this situation. You should not be chasing the dll.

If they did not provide you and you need to chase now, then look into your development computer, that your development and compiled app work well.
For 32-bit app, try to look in C:\Windows\SysWOW64\.
For 64-bit app, try to look in C:\Windows\System32\.

It works flawlessly on my dev machine. It is when I try to install on a “naive” Windows 8.1 that I bump into that mess.