I have an application that allows me to scan images on my development PC which works successfully. It uses the Microsoft Windows Image Acquisition COM ActiveX dll. I am running VS2008 on Windows 7 64 bit.
I am having problems trying to deploy the Interop dll using ClickOnce. This component is referenced through the VS project in the normal way (and copy local = true). When I install the application on a Windows XP machine, I get an error saying that the library is missing (i.e. it wasn't installed / registered correctly). Having looked in the System32 directory, the dll is not there, so it has to be deployed via my app.
After looking on the web and trying various solutions, I then tried Microsoft's 'Registration-Free COM' method here: http://msdn.microsoft.com/en-us/library/ms165432%28VS.80%29.aspx
However, changing the Isolated property to True then caused 2 compilation errors due to duplicate entries in the registry. Having sorted out these entries out manually, I then deployed my app again with the supposedly isolated COM component, but when I try to scan a document I now get this message:
'The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll'
I feel like I'm going round in circles with this one. Can someone please enlighten me on how to deploy the WIA interop via ClickOnce for all versions of Windows from XP onwards?
Your help will be greatly appreciated.
Thanks
Don't copy system DLLs from your Win7 machine to the XP machine, that can't work. It would have been easier if you named the file, I would guess at wiaaut.dll, the WIA Automation provider. It probably just isn't installed on the XP machine.
Ask the client to install this download on the machine. You don't need reg-free COM, these are system components.
Related
I have built a program using Visual studio 2013 in visual basic. I am using a set of DLLs to communicate to some external hardware. The computer I developed the software on is a Win7 64bit machine and I can compile and run the software with no hiccups on it. I also have another computer (Surface Pro 3 64bit) that I use to test my software on and that works as well. Basically I just locate the debug directory of the development computer and copy the EXE and support DLLs to the new computer and run the EXE. This all works with my surface pro 3 computer.
My company purchased some other surface pro 3 computers for our production department and I am trying to get the software running on those as well. I do the same thing. Grab the EXE and support DLLs from the debug directory of the development computer. Except on these computers when I run the software program it tells me it can't find the DLL for the program. The DLL is sitting right in the application's folder, yet it says it can't find it.
I have tried multiple things, like publishing the software and including the DLLs in the installation, then running the installation on the "problem" computers. This still doesn't work. Same issue, it can't find the DLL.
This could be a number of things:
Incorrect version of .NET - do the new computers have the target version of .NET installed on them?
A required DLL is not being found, you should enable assembly bind failure logging and try again - How to enable assembly bind failure logging (Fusion) in .NET
So it turns out that the DLL I was referencing requires the VC++ redistributable packages to be installed on the computer. I downloaded and installed these on all of the problem computers and now the software recognizes the DLL and run.
I have not enough knowledge on how to fix this. What I do know is:
Build a Executable in Visual Studio 2010 on Windows 8.1 (hence the 1-2-0.dll)
Running the executable, crashes on Windows Vista with the message: "This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Under vista you would have the libraryloader 1-1-0 if not mistaken?
this library is linked from mscorlib.dll somehow? But not referencing this dll would not build the project.
Maybe someone could direct me in correct way? Or better have a solution for this?
Is there a way to tell VS to not use this latest dll version?
I am certain I did not reference this specific DLL.
I got the same problem, in my case I was providing the d3d9.dll and d3d11.dll, that I copied from windows 8.1 windows instalation directory and ofc. I cant use those!
And then all Computers like Vista, Windows 7 and even Windows 8 had that Error:
"This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Because this file:
api-ms-win-core-libraryloader-l1-2-0.dll belongs to Windows 8.1
Solution?
In my instaler, Installshield, I removed the d3d9.dll and d3d11.dll, so my aplication will use the ones already in OS.
The problem was not in the "EXE" produced by Visual Studio, but in DLL dependecies that I was providing.
this problem occurred due to Compatibility with older operating systems.
this link may help you
http://msdn.microsoft.com/en-us/library/hh802935(v=vs.85).aspx
I have a vb6 application installed on a server. It works perfectly.
I am trying to relocate it to a different server, however I get an error: "Component: TABCTL32.OSX or one of its dependencies is not registered". TABCTL32.OSX does not exist on this server.
On another Windows 2003 server I get a different error saying another component is not registered. I read somewhere that VB6 is not installed by default on Windows Server 2003 and I read somewhere else that it is. Is there a way to see if it is installed? I am unsure what to look for in Add/Remove Programs. Do I need to install this: http://support.microsoft.com/kb/192461?
As suggested by the topic Windows Server 2003 includes a new version of Msvbvm60.dll this OS certainly does include the VB6 core runtimes. However it is not guaranteed to have the base subset of auxiliary VB6 libraries Microsoft began calling the "Runtime Extended files" in Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, and Windows 8.
In any case tabctl32.ocx must always be deployed anyway since it isn't included there.
The package described in VBRun60.exe installs Visual Basic 6.0 run-time file that you provided a raw link to is a sort of kludge and in any case is only meant for older versions of Windows (NT 4.0, Win9x) in the rare cases where you'd use it.
The VBRun60.exe file is not intended to replace the Package and
Deployment Wizard (PDW) for distributing Visual Basic applications.
For that matter it doesn't contain or have anything to do with tabctl32.ocx anyway.
Essentially what you are asking is not a development question and isn't appropriate for StackOverflow. It is an administrative issue more appropriate to somewhere like ServerFault instead.
If you aren't deploying this application using a proper installation package then that may loosely be considered a development issue, though it still really isn't.
Redistribute and register tabctl32.ocx in your setup.
If you do not have a setup, copy that file - preferably into (32 bit) windows\system32 folder or into the application's folder and issue the command regsvr32 tabctl32.ocx from within a command prompt with administrative privileges.
I have an application that I compile as x86 code but as a separate version, as x64 code as well. The application basically has two parts, a c# managed exe and a c++ unmanaged dll. I have problems with the latter. On my development PC (Windows 7 64-bit, Visual Studio 2008) I create a setup with a deployment project and this setup installs the application in Program Files... as it should and the application runs. I also have a test PC (Windows 7 64-bit with practically nothing else). There the application still installs into Program Files... but it does not run, I get the BadImageFormatException when a function (any function) of the unmanaged dll is called. The problem is that my own project that produces the dll also makes use of quite a few freely available libraries (e.g. glew32, openal, freeimage, etc.) I took as much care is possible to make sure that I use the x64 versions of these libraries, but something still must be wrong. For some reason one of the libraries used by my dll is not available as x64 code on the test PC but it is on the development PC. At least that is the only explanation I have at the moment why my setup works on the development PC but not on the test PC.
My question is: how can I find out where the problem is. The error message I receive does not tell any helpful detail. I tried to analyze my dll with depends but it looks OK. It lists a lot of dependent libraries as X86 (these are probably system files) but all those that I use on purpose are listed as x64.
Is there any way to test why the Windows on my test PC tries to run the DLL as x86 code even though it should be x64?
Thanks.
I noticed something very strange: My application is being deployed in the Program Files folder as it should be for a x64 application but it fails to run. However if I copy all the files in the folder it is installed to to another folder (inside the Documents folder) the application runs perfectly.
Run Fusion Log Viewer in the machine where you want to diagnose the issue. Look carefully at the logs and you'll see exactly which dlls are being loaded, and where from.
You have build your .NET executable (or DLL) with Any CPU configuration, and you have given x64/Win32 native DLL for Win32/x64 (i.e. wrong config).
On x64 systems, your .NET binary will try to load the native DLL as if native DLL is x64.
And on 32-bit systems, it will try to load 32-bit native DLL.
I found the answer. The problem was not the 64-bit dll at all. One of the libraries I did not make but I link to (I do not know which yet, there) seems to try to write a file to the application folder. Of course, this is not allowed inside the Program Files folder unless you run the application as an administrator. Sorry for asking help for the wrong question.
I'm working on some Azure web apps, and in order to debug I'm running VS 2010 as Administrator (I normally right click the shortcut and run-as-admin, I'm aware that there are properties I can change or use Ctrl-Shift).
Windows Azure Tools for Microsoft Visual Studio - The Windows Azure compute emulator must be run elevated. Please restart VS in elevated administrator mode in order to run the project"
If I do this, Azure simulator works OK, but I get two other side effects.
1) I can't drag and drop onto the solution explorer. This is a pain. (Ctrl C/V works but I can't drop whole files into the solution explorer)
2) I develop inside of a DropBox file structure. If I've developed on my desktop, and grab my laptop, projects in my Azure solution that are created within, and shared with, other non-azure projects fail to load. Edit: If I develop outside of dropbox, zip a copy into dropbox, unzip that on the new machine, its all fine.
3) I get "Could not load file or assembly. Access is denied" for various DLL's used by the project - I can fix this for individual DLL's by giving permissions to Network Service but I get the error for resource files too and the same trick doesn't seem to work.
This interworking between machines works fine without elevated privileges - I've been doing it for 2 years on about 20 projects without issue.
So is there a way of running just the compute emulator elevated, or some other way of avoiding these side effects?
OS Version Win 7 Pro SP1 X64
Azure Tools for MSVS2010 Platform v1.4 (11/04/2011)
Windows Azure SDK (11/04/2011)
Windows Azure SDK 1.4.1 Refresh (11/04/2011)
Windows Azure AppFabric SDK V1.0 (29/06/2011)
Consistent over all machines
EDIT: Having already given Network Service user all permissions to the entire folder structure to the project, I get the following error. Prior to doing that, the error was similar, but was for access to the DLL's in the project's bin folder.
Parser Error Message: Access to the path 'C:\Users\ Beko2011Azure\Website\App_GlobalResources\EditorLocalization.uk-UA.resx' is denied.
Source Error: [No relevant source lines]
Source File: /App_GlobalResources/EditorLocalization.uk-UA.resx Line: 1
Version Information: Microsoft .NET Framework Version:4.0.30319;
As far as #1 goes, you can still CTRL+C and CTRL+V to the solution explorer. For everything else you described, the elevated priviliges are probably not the problem. This has especially nothing to do with Azure tools. I have them installed on several machines, and VS works elevated (I always use elevated mode because it's impossible to debug in IIS otherwise). I never had any problems with it.
The DLL/file access denied might be Dropbox's fault. Have you succesfully used this type of file structure in any other projects?
I have no idea what you meant by #2. What fails to load? Azure projects? And do you have the SDK installed on all machines? Same version? Did you mark a web site as hosted in IIS - this also prevents loading of projects.
Also, please update your post with: Operating system version, Azure SDK version...
Update: looking at your error message I can't help but wonder the problem is caused by Dropbox locking files that are needed, and these files then not being accessible by IIS when required. Could you try killing Dropbox service and checking to see if the application performs OK at that point?
As of Azure SDK 2.1 you no longer need to run the Emulator with Elevated privileges. See my answer here