I'm using the FAXCOMEXLib api for sending faxes in C#. I've recently moved to a new development machine running Vista and now I'm running into an issue with the API. Microsoft released a new version with Vista and now when I compile the application on the Vista machine, I can't install and run it on an XP box without getting a fatal exception.
My question is, whats the best way to go about being able to compile and prepare installations on the Vista machine, but still allow the use of the application on XP? Do I have to actually have an XP box available to do a final release compile or is there a way to get around these problems?
Thanks for any help with this problem.
Not exactly an answer but may help:
I got this from Experts Exchange:
After much tribulation, I found a
solution.
The root cause of the problem is
simple: the version of FAXCOMEXLib in
Vista is different than that of XP.
So, when I built the solution in
Vista, it built the Interop wrapper
around the newer version, that found
in the system32 directory, regardless
of what actual fxscomex.dll file I
referenced. So, it was always wrapping
around a version of the file
incompatible with XP.
To work around it, I built the
solution on an XP box, then stole the
Interop wrapper from that build. I
then wrote a batch file that I run
when I copy the build onto the XP box.
The batch file gets rid of the
existing Interop wrapper, replaces it
with the wrapper I stole from the XP
build, gets rid of my assembly (called
fax.dll) that references the Interop
wrapper, and recompiles it from
scratch on the XP box using the
csc.exe tool and the original fax.cs
file. In other words, I essentially
beat the files into submission until
they point to the right version of the
FAXCOMEXLib library. For clarity,
here's the batch file that converts
the Vista-compatible version of the
program to an XP-compatible version:
***** del Interop.FAXCOMEXLib.dll del fax.dll ren
Interop.FAXCOMEXLib.dll.fix
Interop.FAXCOMEXLib.dll
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc"
/t:library
/r:Microsoft.Practices.EnterpriseLibrary.Common.dll
/r:Microsoft.Practices.EnterpriseLibrary.Data.dll
/r:Interop.FAXCOMEXLib.dll
/out:Fax.dll fax.cs
Not very elegent or pretty, but it
does the trick.
I would imagine that this would be an
issue with any old COM .dll on XP that
has been updated to a new version for
Vista.
Thank you cpkilekofp for taking a
look. Admin, you may close this
thread.
Hope this helps.
Related
I'm trying to compile SourceCookifier for Notepad++ 64-bit on Windows 10 with VS2017. I made a few updates to the .sln and DllExport\NppPlugin.DllExport.targets file so it actually compiles and give me a .dll file with no warnings or errors. However, when I put that file in the Notepad++ plugins directory (in a SourceCookifier subdir) and open N++, I get a message box:
A dynamic link library (DLL) initialization routine failed.
SourceCookifier.dll is not compatible with the current version of Notepad++.
Do you want to remove this plugin from the plugins directory to prevent this message from the next launch?
YES | NO
More troubling, if I try the compile on Win7, it produces a DLL that actually works on my Win7 machine. But moving that DLL to my Win10 machines results in the same error on the Win10 machine.
Has anyone compiled SourceCookifier for 64-bit and have it running on Win10?
I don't know C# at all which is complicating this for me.
Cheers.
I have a C# application that uses AutoItX for automation. This application works fine in my Windows 8.1 x64 environment compiled with Microsoft Visual Studio 2013 release 3.
I pushed a copy of the app code to a bitbucket repository and cloned it to a computer running Windows 7 x64. AutoItX version 3.14.2 was installed and the 32bit calls were selected. The application was compiled using Visual Studio 2013 release 4.
The app compiled fine, but the first use of the AutoIt functions resulted in an error:
An unhandled exception of type 'System.DllNotFoundException' occurred in AutoItX3.Assembly.dll
I tried the following steps. The app was tested after each of these steps
Attempted to register the .dll manually using regsrv32
regsrv32 "C:\Program Files (x86)\AutoIt3\AutoItX\AutoItX3.dll"
Uninstalled VisualStudio 2013 R4 and attempted to reinstall VisualStudio 2013 R3 {The installation of R3 failed because it required internet explorer version 10 and version 11 has already been installed on this computer} so R4 was reinstalled
Uninstalled AutoIt and reinstalled selecting the 64 bit library preference. Compiled the app with x64 Platform option
Uninstalled AutoIt and reinstalled using the 32 bit library preference
Compiled the app with the X86 Platform option
Manually copied AutoItX3.dll to the C:\windows\System32 directory
Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform
Wiped computer clean and reinstalled windows 7, AutoIt (32 bit preference), Visual Studio 2013 R4
Installed AutoIt v14
Installed the beta version of AutoIt v15
Performed a Windows update - 213 updates (!) installed
Installed Internet Explorer v11
Performed a Windows update - 4 updates installed
Installed AutoIt version 3.10.2 that worked on the Windows 8 system
I would appreciate suggestions on what to try next. I'm probably missing something very basic, but I just can't find a solution
Manually copied AutoItX3.dll to the C:\windows\System32 directory
Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform
That's the only thing you did wrong, you reversed the copies. There are no other DLLs you could be missing, the AutoItX3.dll and AutoItX3_x64.dll files themselves have no other dependencies that are not already available on any Windows machine. Just operating system DLLs, they've been around forever. Something you can see with Dumpbin.exe /imports.
And the exception message comes out of .NET, it is caused by a [DllImport] attribute. You can see the content of AutoItX3.Assembly.dll with a decompiler like ILSpy or Reflector. There is very little to it, only two DLLs are ever used. AutoItX3.dll for 32-bit code and AutoIt_x64.dll for 64-bit code.
Fairly tragic btw, otherwise a side-effect of ab/using the operating system directories for non-operating system DLLs. The only real way to make sense of why this is backwards is to know the history of Windows.
Back in the early days of Windows when it was still a 16-bit operating system (versions 1 through 3.11), c:\windows\system was the home directory for the operating system executables. Starting with NT 3.11 and Windows 95, the first 32-bit versions, that directory was renamed to c:\windows\system32. When the 64-bit version became available, Microsoft could not rename it to c:\windows\system64 anymore. Too many programs hard-coded the name of that directory in their source code. Breaking those programs would have been a good idea, just not a good strategy to get customers to move to the next version.
The 64-bit version has an emulator that can run 32-bit programs, it is called WOW64. "Windows on 64-bit Windows". The c:\windows\syswow64 directory is therefore the home directory of the 32-bit executables.
Exactly backwards from what the names would suggest. Just reverse the copies and that runtime error will disappear.
Generic advice applies:
The official way to get the loader to tell you about missing DLLs is to enable loader snaps. It is the most reliable way, albeit a bit clumsy.
Dependency Walker has not been maintained for a very long time and produces far too many false warnings. It also has a problem with .NET programs like this, it cannot see the dependency on AutoItX3.dll. You should still get something out of it when you use its Profile mode.
Process Monitor was always the best tool to troubleshoot missing DLLs. You'll see your program searching for the missing DLL, you can tell its name and the directories it looks in from the trace. Start near the bottom working backwards to avoid drowning in the data. I should however note that its been unreliable lately on the machine I use since ~Win81, the trace is just missing stuff I know should have been there. YMMV.
Such an issue can be caused by a missing DLL or a dependency of a missing DLL. I never got good results with Dependency Walker but I have successfully tracked down such issues with Process Monitor.
It should not be a 32/64 bit issue directly, since that would result in a BadImageFormatException instead.
You can debug missing DLL issues like this:
Start Process Monitor
Set a filter for your executable
Reproduce the issue (i.e. run your application)
Save the log in XML file format
Open the XML in Process Monitor Log Analyzer (Disclaimer: I'm the author of that free tool)
Check from top down which DLL is really missing. There may be some where the program can gracefully degrade, so not all of them are necessarily required.
Short solution
Copy and paste the AutoItX3.dll file to /bin/Debug or /bin/Release folder.
Project solution
What you can do is to put in the project's Post-build event command line:
copy /Y "$(SolutionDir)\packages\AutoItX.3.3.12.0\AutoItX3.dll" "$(ProjectDir)\bin\Debug"
copy /Y "$(SolutionDir)\packages\AutoItX.3.3.12.0\AutoItX3.dll" "$(ProjectDir)\bin\Release"
The application I'm talking about consists of vb6 (80%) and c#, .Net Framework 4.0 (20%).
All new components are created with c#. With Microsoft Interop Forms Toolkit 2.1 we create the COM UserControls that we later embed in vb6. For Forms we use normal classes to create and open in vb6 (COM Visible project).
To create the setup we use wise.
Locally everything works fine - The problems only occur when we install the application on a non-developer machine with the wise created setup.
We added a class to open a c# Form to an existing interop toolkit project. It works fine on the developer machine and also when we make a new installation on a pc(non-dev-machine). The new class is just used to open the form.
But when we update our application to a newer version, that class is not working anymore. We have to uninstall the old version and install the new version to make it work again.
Anyone had a similar problems before?
I'm grateful for any advice
This seems like it is an issue with Windows Installer and the sequencing during the upgrade. Does your application allow side by side installs (e.g. Version 1 and Version 2 can be installed at the same time) or does your installer upgrade earlier versions to the latest version? You might try logging the installation and reviewing the log file to see exactly what is happening during the install / upgrade process.
You can log an msi installation by invoking Msiexec from a command line.
This may provide greater insight and help focus your efforts to debugging the problem.
Edit
From what you've described it seems that on fresh installation the install works as expected. When you upgrade earlier versions it would seem that the COM Interop components are not registered properly. This could be an indication that the sequence of events is a little off with regards to when the components are copied to the machine and registered vs. when the existing product is removed. While not exactly identical, see this SO Question and answer for more details. Also, have a look at the RemoveExistingProducts action in Windows Installer for more information.
I would log an installation that you know works without issue (e.g. on a "clean" machine) and then log an installation that you know will fail (e.g. an upgrade) and then compare the two log files using a tool to see if the output is identical. If not, that gives you a clue as to where to look. If they are identical it might be time to engage with the vendor and see if they can assist with determining what's causing the issue.
I installed MonoDevelop on Linux and wrote a shell GTK+ application. When I compile and run the application shows up correctly in Linux. When I move the .exe over to Windows, I get a crash "Windows Not Responding", so there is no stack trace. Then I figured I had to install Mono For Windows, so I did that, but no luck - I still crash.
More generally, I am having a hard time picturing what is going on here. Please disabuse me of whatever I get wrong:
People who started the Mono project wrote their own compiler (likely from scratch) to compile C# code. They modeled this after looking at the .NET Framework
They also wrote a CLR for their mono implementation of the byte code. Any architecture that wants to run this code will need the Mono Runtime, as only the Mono Runtime can run the code.
Do I have it right? Why doesn't my program run? Thanks in advance.
Three things stand out to me:
GTK+. GTK isn't part of windows or mono on windows by default. You must install it separately.
Shell Application. That means something special in the windows world (an app that runs as part of (extends) the windows desktop shell, rather than as it's own program), and I wouldn't be at all surprised to hear that these don't work cross platform very well or even at all. I'd assume you mean "Console Application" instead, but then why the need for GTK+?
Mono. Make sure you invoke the program using mono. Just because mono is installed doesn't mean that's how your program will run vs Microsoft's own .Net implementation.
Hey, I'm only vaguely familiar with Mono myself but I -think- there is an analyzer tool that will show possible portability issues. If you run through that does it show any issues?
Few things you also check.
Is mono installer contains GTK# libraries.
If yes, check that is the assemblies are in GAC. The assemebiles names be gtk-sharp.dll, gdk-sharp.dll
If no, copy the referenced assemblies in your bin directory. you can see that in your mono develop project.
I assume you mean you wrote a GTK# application. In that case, to run it on Windows, you need to make sure you install "GTK# for .NET" from the Mono Downloads page
On Windows, you can capture a crash dump and see what causes the crash. For example, use WinDbg to execute this application.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
My program is written in C# NET 2.0,it's using external functions from a dll written in C++ using Microsoft Visual Studio 2008 SP1.
If I remove the dll from the directory the program is placed,the program crashes at the moment it should use the dll.That's normal.
But the users that are using my program get the same error at the same place without moving the dll.They all have C++ Redistributable 2008 from >here<
Does it happen because I made the program in .NET 2.0 instead of NET 3.5 or it happens ,because the redistributable should be an older version?
Edit:Note for me,the program runs fine.
>>new thread<<
Its most likely the wrong runtime. Make sure you are distributing the correct one. These will always work on your dev box because the runtimes are in the path. For testing software, I use a windows xp virtual machine. I set up the virtual machine as a completely fresh install, install the components I know that I need (.NET framework, etc.), then run my installer. You will run into a surprising number of setup issues doing this.
The C++ Redistributable that you linked to looks like it is from the original release of Visual Studio 2008. If that changes with SP1, I could see that causing the crash. Maybe there is an updated version of the redistributable that your users need to install?
There's preciously little information in your question about the actual crash which could mean any of many things. In my experience with mixing .NET and native C++, many issues can occur in the side-by-side (SxS), especially if the DLL and the .NET application were built with different versions of the compiler.
You probably need to reproduce this problem on a local machine to debug it.
Dependency Walker can be excellent for tracking down these sorts of problems. You can load a DLL into it and it will tell you if any of its dependencies are unavailable. Sometimes missing DLLs are not necessarily a problem (if you do not go down that code path), but it is so much better than guessing.
No difference in this context of using .NET 2.0 or 3.5.
Look in method where you link and export functions from C++ (if it unmanaged)
If external functions had written on managed C++, look into signing and version of dll's