What exactly does the VS project option "Register for COM interop" actually do? Because when I build my library with this option enabled I can call CreateObject on my library from VBScript. But if I build without this and then run regasm manually CreateObject fails. So I'm wondering -- what does VS2010 do that I'm not doing?
It does the same thing as running Regasm.exe with the /tlb and /codebase options. The /codebase option is probably the one you forgot. Regasm likes assuming you put the DLL in the GAC and generates a warning when you don't. The GAC is indeed a very good way to avoid DLL Hell, always a COM problem. But not appropriate on your dev machine, you don't want to pollute the GAC while developing and testing the code. It only matters on your user's machine, the one that's likely to be exposed to multiple versions.
Using the wrong version of Regasm.exe on a 64-bit machine is another way to get in trouble, there are usually 4 versions on your machine. Be sure to distinguish the 32-bit and 64-bit versions (c:\windows\microsoft\framework vs framework64), they write different registry keys. You want to pick the one that's compatible with the client app. Using both is okay too, .NET code can run in either mode, but pretty unusual. And distinguish between the v2.0.50727 (.NET 2.0 through 3.5SP1) and the v4.0 versions. Picking the right Visual Studio Command Prompt is half the battle.
Related
In Visual Studio (C#), ticking 'Register for COM interop' updates the Windows environment such that my Visual Studio project, its dependent Visual Studio projects (in same solution) & dependent DLL files are all available for another COM-consuming application on the same machine. This COM-consuming application works with no issue.
If I want the same COM objects to be available to a consuming application on another machine, what must I do?
I assume I still build with the same flag set (so that the DLL files have COM content)? I assume I must register the COM DLL file (e.g. regasm) - Unfortunately this doesn't work - do I register every DLL file that I am constructing & every DLL file library they reference?
Please make no assumptions about my COM knowledge.
You don't quite provide enough information to answer with certainty, but there are enough hints to guess at what you are doing.
When your client app asks for the COM object, the .NET runtime is invoked and it locates the COM-exposing assembly DLL from the information stored by RegAsm (specifically by the /codebase parameter). But after that, it's all .NET assembly loading rules - including the loading of dependencies.
If your COM assembly has dependencies, the dependent assemblies must be locatable from the client process. It doesn't matter whether the dependencies are in the same folder as the COM DLL - the one loading those dependencies is the process, not your COM DLL. The .NET runtime uses a process called Fusion to decide where to look for .NET assemblies.
You have two practical choices:
Put the COM DLL, its dependencies and the client EXE all in the same folder. This works if there is only one client, and you control the client (so, don't do this if the client is IIS, for example). It's the simplest solution.
Give all the .NET components a strong name and deploy them to the GAC1. You still have to run RegAsm; but don't use the /codebase argument.
It is also possible to customize the Fusion rules by giving the client app a manifest with the proper entries, but that's too much of a hassle. The other options are more practical.
If this doesn't describe your problem, then I would use a combination of SysInternals' (now Microsoft's) Process Monitor and the .NET fusion log functionality to look into where the process is seeking the different DLLs.
1Technically you don't have to put the main COM DLL in the GAC, but it makes no sense to use /codebase for the COM DLL when you have to deal with GAC anyway. At that point you might as well put them all in the GAC
How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).
I wrote a C++/CLR Windows Form program and it works fine on the compiler computer but not on any others. The target computers have .Net4 and the C++ redistribution pack. I really don't understand how the settings need to be set and the info on the web concerning this stuff is very confusing for a beginner. How do I need to have my compiler set so that I can get this program to run? If I need to link .dll's how do I go about doing that. Here are the key settings as I know:
The Runtime Library is set to /MDd; MFC:Standard Windows Libaries; ATL:Static Link to ATL; CLR:/clr:pure.
Edit: If I install VS on taget computers I can open the .exe without a problem, not even opening VS or loading any source files. It seems it's still dependent on VS somehow, any idea's on this and how to over come it?
/MDd specifies a dynamic debug CRT, this won't be installed by the standard CRT redistributable MSI
Try putting a release build on the target machine instead.
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.
So when visual studio build the interop dll it gets 4.0.0.0.
The TypeLib version is 4.0
But the actuall DLL version is 4.0.1.112
Is there anyway I can get visual studio to automatically build the interop DLL to assume the actuall DLL version?
Could I alternatively get the interop DLL to use the version stamp from my app.
I just need to keep the interop DLL current with the app so the installer doesn't leave old interops behind.
I really don't want to do tlbimp manually, but I guess when I get to the point of automating the installer, I could automate that step.
Well, it did consider the DLL version. A type library can only have a major and a minor version number. You'll need to bump your DLL version to, say, 4.1.x.x
This is otherwise appropriate behavior. One hard rule of COM is that you must change the GUIDs if you make a change to a publicly visible interface. Not doing so causes the worst kind of DLL Hell, the kind that crashes the client app without any good way to diagnose the reason.
That's no longer a revision change, that's a non-so-minor version change. The clients of the COM server have to be rebuilt. If you didn't actually change a public interface then having a type library version of 4.0 is still quite appropriate. It didn't change.
I don't believe this is possible. Visual Studio will prefer the TypeLib version when building the the interop DLL. I think you're only recourse is to use a hand crafted DLL with tlbimp and taking advantage of the /asmversion switch
http://msdn.microsoft.com/en-us/library/tt0cf3sx(VS.80).aspx