I have a WPF C# application that makes use of the InkAnalyzer class. On my development platform (Windows XP), I have added references to IACore.dll and IAWinFx.dll for the project before building the release.
However, when I tried to run this on a HP TouchSmart tablet PC (on Windows Vista), the application throws a "FileNotFoundException". Offending file name is IACore.dll.
Next, I selected the "Copy Local" option for both files, and rebuilt the application. However, once that is done, yet another file is not found. This time it is "IALoader.dll".
I realise that I must be missing something on the HP TouchSmart (on Windows Vista). Is the Vista laptop missing a SDK?
A Solution
I couldn't find IACore.msm anywhere on my SDK, and it's a recent SDK (XP Tablet PC SDK version 1.7), so I used Search to find the IALoader.dll, and manually copied it to my application's folder. No more complaints after that.
However, if there's a way for me to avoid bloating my application deployment with these files, it would be great. Thanks for your help, Jared!
Looks like this problem was encountered by a few other people as well. The basic problem is that the assembly is not installed in the GAC but in the Windows SDK directory. In order for your application to ensure it's loaded it must include the IACore.msm in the setup project or manually install the framework.
Full Thread:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/719cbbde-013e-4165-b694-6a994d833352/
Related
The Issue:
Our application is a .NET 5 Windows Desktop application. The licensing capability requires the application to use the System.Management component from NuGet to create a unique device ID from the system processor ID, MAC Address and BIOS serial number.
This all worked great when testing it from Visual Studio debugger. However, when adding System.Management.dll to the application installer (InstallShield installer) I naturally selected the version of System.Management.dll that was in the app's build target folder. It turns out that the version of the DLL that ends up in that folder is a no-op version that throws not supported exceptions saying "System.Management is supported on Windows Desktop Apps only".
The Solution:
I found the correct version of System.Management.dll in the build TargetFolder\runtimes\win\lib\netcoreappX.x folder. In my case, since I'm using System.Management version 6.0, it is in the "netcoreapp3.1" folder.
Conclusion
There are many cases where Microsoft doesn't do the right thing. In this case, my application was specifically a .NET 5 Windows Desktop application, so we would all think that msbuild could figure out the correct thing to do. Not so. In such a case, I would have at least hoped that .NET Foundation would have provided information on this. Well, now you all know now, as well!
Cheers
TOOLS:
Windows 10 Pro
Visual Studio 2017 Pro
I created a VB.NET windows app GUI on my desktop computer,
published it,
copied the publish\ directory to a new target laptop,
logged into laptop and ran publish > setup.exe
it asked me to "install" and I said YES,
and app started, but hung, never displaying the GUI.
My app has two .DLL's of mine, but they are not in the publish\ directory.
I made a HELLO WORLD on original desktop, published, and it ran ok at laptop.
All of your dlls need to be distributed with your application.
Try manually move your dlls in the same folder of .exe file on target machine: if it works simply rebuild your setup incuding these dlls as dependencies.
The problem is solved. The target laptop needed installation of drivers from a vendor of some 3rd party middleware used in the app.
So, the packaging software wasn't smart enough to tell me the problem, and its error correction response was to just end without any error message.
I have a multi-project solution (C#) that I am trying to deploy to one of our test servers. All the projects are being built for x64, with the 'Prefer 32 bit' disabled where applicable.
Some of the projects reference a SQLite dll set that uses the SQLite Encryption Extension (not managed by nuget). When I build and install the solution on my local dev machine, the application and windows service are able to function properly, no problems.
When I try to install the same package on one of our test servers, running 64-bit Windows Server 2012, I get the "Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found." whenever I try to communicate with the SQLite database. I have triple checked that all the appropriate DLLs are in the program folder after installation.
In my VS solution, I have tried creating the x86/x64 folders, setting Copy to Always, but to no avail. I have also copied the DLLs from my local install folder into the server folder just to see if something got messed up along the way.
Could it be a permissions issue? I'm an elevated user but not a full admin on the server, whereas I'm a full admin on my machine. I've tried manually modifying the permissions on the program folder to see if that was an issue, but had no luck with that either.
So to summarize, the project is being explicitly built for x64, it has the right DLLs in the right folders, and it works on a local install. I'm at a loss as to why it won't work on the server install. I've looked through countless threads on StackOverflow, MSDN, and SQLite's website, all usually suggesting the x86/x64 folders, but that hasn't been working for me. I'm hoping someone can help me out here.
Thanks!
Was actually able to figure it out after a bit more debugging. The Visual C++ runtime that was installed on the server wasn't the right version. I added the Merge Module to the installer for the version my project was expecting, reinstalled the app on the server, and now it's working beautifully.
For those who have this issue, look for the right version of the VC++ runtime in C:\Program Files(x86)\Common Files\Merge Modules. If you don't know what version you need, use something like dependency walker on the machine that is throwing the error. Mine told me I was missing VC140, so that's the module I copied into my project and added to the installer.
I have made a Kinect Application in Microsoft Visual Studio 2010. I need to make an exe of the application which can run on any windows based system. If I need to do that than is there any requirements that the system should fulfil? and If yes, then how do I do that?
I tried to use the exe in application/bin/debug/application.exe by copying it in another folder but it shows an error but if I run the exe from the bin/debug/application.exe it works. Am I missing something here or is it the only way to do that?
"Any Windows based system" isn't going to work. Assuming you're using the Kinect SDK, it will only run on Windows 7 (and supposedly Windows Server 2008). The computer running the application will need either the Kinect Runtime, which only works with the new Kinect for Windows sensor, or the Kinect SDK, which also works with the Kinect for Xbox. Microsoft wants to sell more Kinect for Windows sensors, so they don't allow the runtime to work with the old Xbox Kinects. Makes sense in a way, but man that bugged me when I first found out about it. There's a short post showing how to test for the existence of the Runtime on application load, so you can show an appropriate error message instead of just crashing out.
You need to copy any files that the program relies on, such as DLL files, along with the executable. There's instructions here for how to embed the DLL files into the executable; I've not tried it but it might be worth a shot.
The correct .NET version should be installed when either the Runtime or the SDK is installed; you shouldn't have to worry about this.
#Coeeffect is right, but you can also publish version 1.0.0.0 of your app by going to project -> properties -> publish -> publishing wizard to publish your application to then use on ther computes ect. Hope this helps!
You need to copy all non-standard DLLs that your program uses.
The target computer needs the appropriate version of .Net.
I am developing a 32bit WinForm app (target: .NET 3.5). My client insists the app be installed into "Windows\System32\clientname" folder and autostarts on startup. Also, the app must be 32bit, so I can't use "Any CPU".
I am developing under Win7 x64 with VS2010 and all versions of .NET are installed. When I start the app I get the message "Unable to find a version of runtime to run this application".
On Win7 x86 it works without problem. It's not the app itself and I am 100% sure all the required frameworks are installed.
I know that on a x64 system this folder is not to be used for 32bit apps but as I said: client insists and won't budge.
Before I tell client definitively that it can't be done I want to explore all options. I googled of course and also searched this fine site but nothing helpful for my particular situation came up.
My app spawns another 32bit process located in the same folder. On x64 that didn't work either, of course, but I solved that by using "Wow64DisableWow64FsRedirection" and then copying it to another location to start it from there (which works fine).
I have done my homework but I just can't find a solution for starting the main app under x64 and in that particular folder.
Is there one?
In an attempt to solve this problem I created two folders on my Win7 x64 machine:
C:\Windows\System32\ClientName; and
C:\Windows\SysWOW64\ClientName
Next I created a simple x86 WinForms application targeting .NET 3.5. I found that if I copied the executable to C:\Windows\System32\ClientName I got exactly the same error message as you reported.
However, if I copied the executable to both directories, then I could start it from C:\Windows\System32\ClientName, and it worked just fine.
I did not try this, but I suspect that if you have a multi-assembly application, you only need to copy the *.exe file to C:\Windows\System32\ClientName. All of the other files (and the EXE) would then reside in the C:\Windows\SysWOW64\ClientName directory.
This is a bit of an untidy solution, I know, but then again your client's requirement is a bit unusual to start with.