I am currently trying to build on TeamCity, which uses Microsoft.Office.Interop dll. This will build and work fine locally as I have Office installed, however when trying to build it on TeamCity it fails as it has no reference.
I can't install the PIA distributable as I get an error message saying the Office 2003 is required to be installed. I don't want to install Office on the server.
Is there any way to get around this?
If all the teamcity server is doing is a build, then add the Microsoft.Office.Interop DLL to a References folder for your project, and then configure your project to look in that references folder.
However, if the TeamCity server is also running tests that use Office Interop, then you will run into problems unless you have Office installed on the machine running the tests.
Not really - the Interop dll is only a thunk layer between your .NET code and the actual (COM) Office code. If you have the Interop dll without the underlying Office dll, then any calls into the Interop will fail because the Interop will want to call the COM objects it's making interoperable.
Those COM objects are Office objects, so you will need some part of Office installed.
Related
I have an EXE in VB6 that calls a recently upgraded to VB.Net DLL. This part is working fine, but the issue that I am running into is related to locating the interop of another COM DLL the VB.Net DLL references.
An overview: EXE (VB6) calls method A of DLL (VB.Net), no issues. Method A of DLL calls method B of third party DLL (COM), it gets an error of not being able to find the interop file of the COM DLL.
I have tested directly in VB.Net using a test UI to call the same method A in the VB.Net DLL, and everything works fine. I am currently at a loss as to what is causing the issue.
Thanks,
Chris
I have finally found the answer to the issue. All said and done, the issue was that the interop assemblies were framework version 4.0 instead of framework version 2.0. Visual Studio created them this way for some reason, so I had to change them by using Visual Studio 2008 to create new versions of them.
The process to find this out (which most of is already stated above, but repeated here for helpfulness) was to place all my VB.NET dlls and the interop assembly dlls in the directory of the VB6 exe. (I created sub folders for each one for easier cleanup later.) This still resulted in the same error, but the assembly builder log showed a different reason for the error. This time it was able to load the assembly without issue, but was not able to complete the setup of the assembly.
Researching this led me to the idea of checking the framework versions of the interop assemblies using ILSpy to find out they are version 4.0 while my dlls are version 2.0.
Initially I tried recreating them in Visual Studio 2017, since my project uses framework 2.0, but it still created them as framework 4.0 for some reason. I then tried in Visual Studio 2008, and it was able to create the correct framework 2.0 versions of the interop assemblies, and now everything works as expected.
I am trying to set up .Net builds on our Hudson (CI build) server. One application uses Microsoft.Office.Interop.Excel.dll. This is not found on the build server and causes the build to fail.
I obviously don't want to install Office on the server just for this case so what do I do?
To clarify: this is a build server. The project is not run on the server and Excel is not needed except to satisfy the compiler.
Install the primary interop assemblies:
Office 2003: http://www.microsoft.com/en-us/download/details.aspx?id=20923
Office 2007: http://www.microsoft.com/en-us/download/details.aspx?id=18346
Office 2010: http://www.microsoft.com/en-us/download/details.aspx?id=3508
Those PIA's should be also deployed to the GAC when you install Visual Studio (if you can).
You might also take a look at this question: Unit test with Microsoft.Office.Interop dll fails on build server
This is straight forward if you are using nuget and any repositories like nexus for dependency management. In our project we use VS2017 which has msbuild nicely integrated with nuget and it does the job to download this dll locally and on build server.
Hope this helps
I have one problem in vb6. I created a .tlb file in VB.net 2005 by adding Com class to project. I built the project, I got .tlb file and .dll files while building project, i selected "Register for Com interop" from project properties and built. It registered autometically and I can use created .tlb file in that PC in Vb6 working fine. if I deploy application to another PC and run I am getting "Error 429 ActiveX Component Can't create object" run time error. What I need to do? Please help me as soon as possible. I can't deploy the application to client due to above error.
one possible solution is to install .net frame work on client pc i never want to install .net framework any other solution will be most appreciatable.
If you've created a DLL in a .NET language (such as VB.NET), the target computer must have the .NET Framework installed in order to use the DLL.
This a hard and fast requirement, irrelevant of how you're utilizing the DLL, whether from a VB 6 application through COM interop or otherwise. It is also a hurdle you'll have to jump over first, before you worry about things like registering COM components, as Uday's answer suggests.
If you don't want a dependency on .NET, you need to use another environment to create the ActiveX DLL; either C++ or VB 6 are possible choices.
One option may be that, while deployment, you need to register that .tlb file in System Registry using regsvr32 command in command-prompt. Generally static libraries does not work until they are registered with System Registry.
You might have seen many programs register components during installation like 'Registering Type Components' or 'Registering COM Components' (for those who do networking especially). Those components are nothing but native COM dlls and tlbs.
so when creating deployment project, add some scripting login to register thode dlls and tlb to System registry using:
regsvr32 <path to tlb/dll>
you have to recursivey call this command for every dll/tlb you want to register with system. For example, if you have 4 dlls and 2 tlbs then you have to call it 6 times providing the path of dll and tlb one at a time.
I have a C++ DLL project which is created in VS 2010. It is exposed as COM(ATL). I used this dll to another .NET Project as reference. C++ Project linker settings are set as follows:
"Register Output" = Yes
"Per-user Redirection = Yes
I created a build definition to build these two projects in tfs 2010. C++ Project builds fine, but .NET project fails because the output dll of C++ project is not registered. Setting to "Per-User redirection" = false does not work. I also tried using WF activity 'InvokeProecss' to register the c++ dll using Regsrv32/batch file/my own exe etc, but I get exit code of 5. My TFS 2010 is in Windows 2008 Server R2. And I think, it's not running the process as admin.
If I generate a interop dll using tlbimp, and then I refer that interop in my .NET proejct, it works fine(oviously in tfs build, I need to add InvokeProecss to call tlb). But this is not acceptable as our general practice is to refer a COM dll directly from .NET proejct.
Can anybody please help about this?
Is there a way to run the tfs automated build activity 'InvokeProcess' as Administrator without prompting for user name/password?
By default, the TFS Build Service runs as the "Network Service" account which is a relatively low-privilege account. Alternatively, you can configure it to run as any domain account you like. I wouldn't recommend that as a solution to the problem you described, however. I would agree with Hans that, in this case, it would be better to use the type library importer (TlbImp.exe) to "reference" your COM server from your managed assembly.
If the COM object isn't changing, you can just use the type library importer to generate an interop assembly, check that in and reference it from your .NET project. If it is changing, you can add a post-build step to generate the interop assembly rather than using the InvokeProcess activity. As Hans pointed out, you can't actually reference a COM object directly from a managed assembly. Your reference is actually causing an interop assembly to get generated at build time after resolving the reference to the registered COM server.
I had a C# program that did some Word & Excel automation and it used Office 2003 Primary Interop Assemblies. The way I deployed it was by including the Interops in the bin and I had my program reference it from there as opposed to referencing it from the GAC (not very professional, but it worked fpr years). Recently on 3 machines the office 2007 compatibility pack was installed and now when ever my software trys to invoke Word or excell I get an error that:
Unable to cast COM object of type Microsoft.Office.Interop.Word.ApplicationClass to interface type Microsoft.Office.Interop.Word.Application, This operation failed because the QueryInterface call on the COM component for the the interface with IID {00020970-0000-0000-C000-000000000046} failed due to the following error: Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
After some searching I noticed that installing the compatibity pack Word11 and Word12 were both installed in the GAC and the same with Excel.
I attempted to have my program reference the Word11 interop in the GAC and still no help.
I unstalled the Word12 interop and still no help.
It seems that installing this seemed to have changed some registry setting or something that my software is confused cannot find the correct library.
Anybody have some ideas?
I recently had this issue with word too and I tracked down this registry key as the culprit
HKEY_Classes_Root\TypeLib\{00020905-0000-c000-000000000046}\8.4
Apparently this tells the word to use word 2007 introp assemblies instead of Word 2003 (8.3). At least I think I am not too familiar with office introp assemblies. I delete the registry key and everything worked as normal. I do not know of any adverse effects from deleting this key, but definitely back it up.
I've worked around this by copying the earlier versions from the GAC to our Third Party libraries folder, and reference them there -- also means you can build against 2003 with only 2007 installed. (and yes, I know this is a really dirty hack)