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
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
I have a C# project in which I have a COM Reference. It compiles fine when opened in VS 2013. But, it fails as part of TFS build definition.
TFS version : 2013
TFS Build Controller & Agent : 2013
VS version : 2013
The failure message says that it could not find the Interop dll. I cannot manually create the Interop dll and check-in into TFS because it would keep changing and I want my C# project to always take the udpated COM reference.
I tried the COMFileReference suggestion but it did not solve my issue. I even manually registered the COM dll using regsvr32 but still I am facing the issue.
Any help is highly appreciated.
Regards,
kvk1985
A COM reference is the safest way to ensure that your program matches the actual installed component when you test your code. The compiler will read the type library of the component, a very similar mechanism that's used for normal .NET assembly references. Except that the type definitions come from the type library instead of .NET metadata.
But has a disadvantage in your case, it can only work when the component is actually installed on the machine. That probably did not happen on that build server. That's fairly normal, the people that maintain build servers don't particularly like anybody messing with it. And it is a maintenance headache, the build breaks when the devs update their machine with the latest version but forget to update the build server as well. And old builds get to be hard to reproduce.
So installing the component on the build server is the Quick Fix. If that's an insurmountable obstacle then somebody needs to run Tlbimp.exe on their machine. That generates the interop assembly, it needs to be checked-in to source control. And the project must be modified, remove the COM reference and add the reference to the generated interop library. It will now build the same way on the build server and the dev machines.
That's of course brittle the other way, if a dev updates the component on his machine then there will be a mismatch with the interop assembly. That can be a very ugly one, an E_NOINTERFACE runtime error if the COM vendor did it right, something excessively nasty like calling the wrong method, a stack imbalance or an AVE if he didn't. Otherwise the exact same kind of failures that can occur if the user's machine doesn't have the right version of the component installed. Standard DLL Hell.
You'll have to make the call yourself, there's no One Right Answer.
I'm writing a simple C++ application in Visual Studio. It also has a setup project.
It works well on my development machine, but when I'm installing this application on user's machine it requires Visual C++ Redistributable Package. I'm wondering why does my application require C++ Redistributable? Standard C++ runtime library is shipped with Windows, isn't it?
The only version of the C runtime library which is shipped by Microsoft with most of 32 bit Windows versions is msvcrt.dll. This library provides a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, etc.
Visual Studio 6.0's compiler links against this library, so if you are developing in VS 6.0 you shouldn't encounter any problems on most users' machines.
However, if you are developing in VS 2005, VS 2008, VS 2010, VS 2012, VS 2013 or VS 2015, you have to distribute additional C runtime libraries along with your application. This is because their compilers link against msvcrt80.dll, msvcrt90.dll, msvcrt100.dll, msvcrt110.dll, msvcrt120.dll and msvcrt140.dll respectively, which are not shipped with Windows.
Solutions:
Possible solution is to link statically with runtime library, but it may cause a lot of problems in case you have both .exe and .dll in your application. Don't do that.
To be more specific, I'll allow myself to quote a part of this answer:
Using /MT is risky if you create DLLs as well as an EXE. You'll end up
with multiple copies of the CRT in your program. This was especially a
problem with earlier versions of VS where each CRT would get its own
heap, not so much with VS2012. But you can still have ugly runtime
problems when you have more than one "errno" variable for example.
Using /MD is highly recommended to avoid such lossage.
Another possible solution is to require an appropriate Microsoft Visual C++ Redistributable package to be installed on the user's machine.
It may be done by specifying this requirement in prerequisites property in your setup project.
Also, you can distribute the runtime dll by including in your setup project the appropriate "merge module". In this case don't forget to add the appropriate "policy merge module" to avoid errors caused by incorrect runtime version.
Finally, you can just put required DLLs in the same folder in which your application is installed.
Further reading:
"Redistributing Visual C++ Files" - Official MSDN documentation
Even though some comments said that «link statically with runtime library, but it may cause a lot of problems when you have both .exe and .dll in your application.» this is NOT TRUE. First we DON'T statically link DLLs! We statically link OBJs and LIBs. LIBs are static libraries; DLLs are dynamic libraries, and you may choose to use LIBs (static) or DLLs (dynamic). It's entirely up to you to choose. The ONLY drawback (for the DLL fans) is that if you want to update one library, you need to compile and link again. I personally deploy ALL my software static linked and because of that I earn the bonus of don't even need installers. The software I develop is 100% portable (a feature that in the pre-installer era was general procedure), and the final user is free to simple COPY from one folder to another or even from the hard drive to flash drive (or vice-versa). The error message «DLL not found.» simply doesn't exist ... NEVER.
Some folks think of statically linking as toy software: WRONG! I can write a full featured application that connects to a DBMS (Oracle, SQL Server, ...) or any other kind of application.
I have a C++ dll. Is there a way to compile it so that it can be used with VS2005/2008/2010 instead of me having to do 3 different builds?
Thanks
You can generally "use" a C++ dll with any version of Visual Studio, if you're just linking to it.
However, when your dll is compiled, it will be targetted to a specific version of the C++ runtime, so end-users of your program will need to have that runtime (Visual C++ redistributable package) installed on their PC. So if you use a dll built by VS2005 and an exe built by VS2010, your end user will have to install both the 2005 and 2010 redistributable packages. The same generally goes for other libraries if you use them (MFC, etc)
If you do this, you will also have to be careful about memory allocation - memory allocated in one runtime version cannot be safely deallocated by another. So anything that your dll allocates must also be deallocated by the dll, and anything allocated by your exe must not be deallocated by the dll.
As a result, most people will rebuild the dll with the same version of VS as they build the rest of their program in, to minimise the compatibility issues - ultimately it's much easier to build in each verison of VS than to sort out all the issues involved in not doing so.
(Hint: You can run VS from the command line and get it to build a project/solution, so it's a 5 minute job to write a batch script that will automate building all three variants in one go)
The version of visual studio in use doesn't make a difference as to whether a given assembly can be referenced.
The only thing that matters is what version of the framework the assembly was compiled against.. Assuming it's a .net assembly anyway.
Regardless, it's common practice to provide versions compiled against each framework rev (2.0, 3.5, and 4.0) anyway.
However, if you are compiling an unmanaged c++ dll; then just provide a 32 bit and a 64 bit version of that dll. In this case the .net version in use (and visual studio version for that matter) is immaterial.
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.