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.
Related
I am using Visual Studio Professional 2010 and the Team Foundation Server Express (beta). My VS Project (C#.Net / WPF) has been migrated from VS 2008 (without TFS) to VS 2010 (with TFS).
Whenever I apply changes to my code and try to debug my application, I get messages like This breakpoint will not be hit. (in german: Der Haltepunkt wird momentan nicht erreicht. Der Quellcode weist Unterschiede zur Originalversion auf.) and the project is started using the old executable version (the one with the last successful build). No errors occure, the code is OK, but the changes are not applied either.
When I manually cleanup and rebuild my project, everything works quite fine - but there has to be a fix for this issue?
Edit: I just added a new project to my VS solution and checked it in on the TFS Server. Using this new project the problem does not occure. Even when I add the same dependencies I used in the project mentioned above, the debugging and building of the new project works fine without the errors mentioned above.
Maybe this information helps you to lead me to a solution.
It's not clear whether existing answers are not sufficient. I can't know exactly what's causing your problem; but, I can detail some places this potentially comes up.
The first area that I commonly see this is when a project references an assembly directly. You can create a project that creates an assembly. Another project might use that assembly and you can reference by assembly directly (and not add a reference to the "project"). This disconnects VS from really knowing it needs to "build" that referenced assembly first and it will sometimes get out of sync with the debugging symbols (PDB). You can tell if a project has been referenced or an assembly has been referenced in the properties of the reference (expand References in Solution Explorer, right-click a reference, and select Properties). A referenced project will not have a Specific Version property, while an assembly reference will. You can sometimes also tell from Project\Project Dependencies. If you have a reference to an assembly generated by another project but that project isn't a dependency in Project Dependencies, it might be an assembly reference. To fix this, you can usually just delete the reference and add a reference to the project.
I've also find that sometimes breakpoints confuses the debugger. If I have many breakpoints or they've been kicking around a long time, the debugger sometimes does some weird things. If I delete all the existing break points (Debug/Delete all breakpoints) and re-apply them the debugger is usually much happier.
You can find the answer here. The assemblies might be in GAC or a project or some projects need to be rebuild to generate the pdb files again, which are used for debugging. If you don't choose to rebuild it might use the old pdb files.
My guess is that you are putting breaking points somewhere your program can't access them.
Ex:
const int x = 5;
if(this.x == 1)
//do sth <--- breakpoint here
If you are running a mixed mode application (unmanaged native C++ & managed C#), make sure to set Enable unmanaged code debugging in your C# application's Properties window.
You have to rebuild, there isn't an easier way around it.
The program database files (PDB) need to be recreated. You should also have your configuration setting set to debug.
Also the first answer to this question must be of help as well.
This happened to me when I started VS as an admin, and it also happened to me when the project is set to a different architecture than a DLL that I used in this project.
I have a Visual C# Project that is fairly basic (no more than 100 lines) but it includes some 3rd party DLL references. Running the project on the computer it was developed on has it run just fine.
In Microsoft Visual C# 2010 Express, I go to Project->Publish <project name> and it builds some files including a setup.exe installer.
When I move those files to another computer and run the setup.exe, it correctly installs the program.
But when I run the program, it simply closes out saying:
ProjectName.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
The command window also appears for a brief second with some errors, but it's hard to make out what it is saying. It looks something like:
Unhandled Exception: System.Runtime.InteropServices.COMException: Retrieving the COM class factory for the component with CLSID { ....... } failed due to the following error: .....
I'm unable to get the command window to stay, so I cannot get the full message. But I assume this is due to the other computer not having those 3rd party DLLS.
How can I have Visual C# 2010 package everything including DLLs so this error does not appear? Or if that may not be the actual issue, how can I stop the command window from instantly vanishing? (I do not know the full list of DLLs required)
Or if the DLL is a registered DLL under C:\Windows\system32, is the project never going to build that into the package? Is there a way to see what it depends on?
Visual Studio 2010 Express doesn't create fully functional installers, but only ClickOnce installers, and those also with limited functions. This kind of installer can't register COM DLLs.
What seems to be wrong in your case is that you are using a COM DLL which isn't registered on the target system. You could try to check that in your own program (like trying to create the class and catch any exceptions that are thrown by the CreateObject function), and call RegSvr32.exe /s in order to register it. Or you just do this when the program starts the first time, before you create any object from the DLL... haven't tried that, though.
You could also make sure that you register the DLL manually on the target system before you run your program.
Moreover, when .Net uses a COM DLL, it usually creates a compatibility assembly which wraps the COM DLL and makes it accessibly to .Net. In case the DLL you use is only this compatibility assembly, you might have to locate the COM DLL it depends on manually on your system and to include it explicitly in your project's files.
In order to debug, it should be enough to put try / catch blocks around CreateObject. If that doesn't help, try adding an eventhandler for the event that is raised when an exception isn't handled by the application (this might be different according to the kind of application you create).
I have a C# 4.0 application that is referencing a type library from a C++ application. This is used for some secure COM interop, a question I originally had asked here.
On my development machine this second application is installed so I can compile without any issues. If I attempt to compile on our automated build server, or any machine with Visual Studio installed but without this second program, I receive the following errors and compilation fails:
Text for google:
The type or namespace name could not be found (are you missing a using directive or an assembly reference?)
Cannot get the file path for type library "guid...." version 1.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
The referenced component 'SecurityAgentLib' could not be found
Picture for readability:
I'm not sure how to get around this other than by installing the application that registers the actual dll that implements these types, but I don't want to do that on our build server. The code that uses these types are wrapped in a class that is never instantiated unless prerequisite checks are run to verify the app is actually installed, so there is no chance of a runtime error. In fact I can run my app just fine on a machine without the second app installed - I just can't compile it there.
In visual studio the reference points to the .tlb file which is included in the solution directory, so the tlb file itself is present.
I can't imagine it should work this way, and I've searched around, but I'm apparently not searching for the right terms.
EDIT:
Running tlbimp.exe generates a dll but the type library should be sufficient for compilation, I thought at least. There is also an issue of broken references. I was reading this article Troubleshooting Broken References and it says that if the reference was to a COM component that is not installed than installing the component corrects the error, which is true.
Installing it on the build server really isn't an option. Opening visual studio and re-adding a reference if the path was broken doesn't work either.
I was able to use tlbimp to create a dll and used visual studio add a reference to that dll. That let me compile, but how would this work in an unattended build server?
EDIT
Okay I came up with two solutions that worked given my requirement of this all being unattended
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll in visual studio and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but if needed the build server could make modifications directly to this file to remove the tlb section and add a reference to the dll following a build of the second product.
Here are a couple options that each worked.
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but the build server could make modifications directly to this file to remove the tlb
I'm attempting to find the minimum installation requirements for getting WP7 projects compiling on a Windows 2008 R2 build server. I'll be looking into automated testing using the emulator at a later point, but right now I'm stuck on the build side.
I realise this approach won't be supported and I'm willing to trash the VM at a later date if an update proves to be incompatible (assuming I get it to work at all)
I'm also aware of the workaround for installing the entire SDK on Windows 2008 R2, but I'm trying to avoid installation of Visual Studio (it's now become a curiosity more than anything else)
As it stands, I've installed the following from the SDK ISO:
WCU\Silverlight4\silverlight_sdk.msi
WCU\WindowsPhone\WindowsPhoneExtensions.msi
WCU\WindowsPhone\VS_SDEProLightup-enu.msi
At this point, it is able to locate all the required MSBuild target files and even compiles the project. The problem appears at the end of the process during the XapPackager target, when it errors with:
Xap packaging failed. Unable to load DLL 'zlib114.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Using Process Monitor, I can see that MSBuild finds the dll in the WP7 MSBuild targets directory that installs with the SDK with the only error being "FILE LOCKED WITH ONLY READERS" error to a CreateFileMapping+SyncTypeCreateSection, which it then falls back to a SyncTypeOther, which succeeds. Despite this, MSBuild still continue to look for the dll is all the other standard locations (Framework directory, SysWOW64, etc).
Any thoughts to why it might be failing?
If you're using TFS, Justin Angel has a great post on TFS2010 WP7 Continuous Integration. Given that TFS is just wrapping around MSBuild, you may find this a particularly useful resource. When it comes to doing the unit test integration, Deyan Ginev from Telerik has a series of posts that covers this.
FYI, I ended up fixing the zlib problem by using the dll from the Silverlight SDK, rather than the WP SDK.
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