When I add a reference to Microsoft.Office.Interop.Excel on my computer, Visual Studio adds this to the project file:
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>5</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>primary</WrapperTool>
<Isolated>False</Isolated>
</COMReference>
There is another developer on the team who gets errors and needs to add a DLL file to the project called Interop.Excel.dll, which replaces the code above with this in the project file:
<Reference Include="Interop.Excel, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>My Project\Interop.Excel.dll</HintPath>
</Reference>
This does work on my computer.
Could you please explain the differences between the two methods, which is best, and how to get the first one working on other computers?
I don't see a problem with your approach either.
Typically VS will generate an interop assembly for COM components automatically when you add a reference to the component. However, when you add a reference to one of the Office components (XP or any later version), a reference to the pregenerated (and optimized) primary interop assembly from Microsoft is added as in your first example. The line
<WrapperTool>primary</WrapperTool>
means that this PIA is used.
If you correctly added the PIA reference the CopyLocal property of this reference should be set to false and the Path property should be something like
C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll
You will find some more details on interop assemblies in this MSDN article.
To get the first method working it is necessary that the Office Primary Interop Assemblies (PIAs) are installed on the machine. There is a redistributable version available from Microsoft:
Office 2003 PIAs
Office 2007 PIAs
AFAIK, these PIAs only get installed by the Office setup when the .NET Framework has already been installed, that's why there is a separate redistributable for the PIAs.
Note: Make sure that you reference the version of Office that you are targeting. When targeting several versions of Office, you might get some problems however. A solution in that case might be late binding (if performance is not an issue).
I've used Excel automation way more than I would like to admitt, and I have never referenced Interop.Excel.dll. I've always referenced the former. Why is he referencing that, and what errors does he get?
Are you guys referencing the same version of excel (5.0 verses 11.0)? Do you guys have the exact same version of office, service pakcs and all? This could be the differance.
I found the cleanest way to use it, this also allows for multiple versions of the interop, is to create a shared bin\Office Interop\11 or 12\Microsoft.Office.Interop.Excel.dll\ and refeferenced them from the project, works a treat for different version
Related
I have found some free compilers online, but I can't figure out how to add external references to any of them. Is there a special Imports statement I can use, so that VB.NET will go looking for a third party .dll in a certain relative path, so that I don't have to add references through Visual Studio? The specific reference I am trying to add first is the DI interop for SAP B1, but this probably isn't going to be the only one I will need to add.
I know that I can add a /reference to add a reference in a command line compilation, if I am using Microsoft's command line compiler, but that seems to be against the license for my client now. I gather the old Express 2010 versions could compile and add references without revenue restrictions, but I am looking for syntax on how to tell a compiler to add a reference, not a software recommendation (since I don't think I can still get those Express editions).
The answer is as #Jaxedin and #T.S. said in comments to the question, but I wasn't aware of the existence of the MSBuild software.
I had read in various places in reference to MSBuild comments like "And keep in mind that for now, you’ll need to have Visual Studio 2015 installed in order to build the first time." (MSDN), and just took them for face value.
Being able to put the references inside an XML .vbproj is much easier than I had been imagining. Something like:
<ItemGroup>
<Reference Include="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<Name>System</Name>
<SpecificVersion>True</SpecificVersion>
<HintPath>...\systemDir\System.dll</HintPath>
<ReferenceOutputAssembly>True</ReferenceOutputAssembly>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Reference>
</ItemGroup>
I am a .NET Developer. I have a good understanding of how references work in .NET i.e. if you want to use AssemblyA.ClassA.MethodA in AssemblyB.classB.MethodB then you add a reference in Assembly A to Assembly B.
I am looking at a VB6 app and I get an error when I open it i.e. Errors during load. Refer to frmMain.log. I open frmMain.log and it says: "2142: Class MSComDlg.CommonDialog of control CommonDialog1 was not a loaded control class.". I have used WinMerge to compare the source code in the faulty project to a previous version of the project (which does not have the problem). The only difference is that the faulty project contains the following line in the client.vdp file:
Reference=*\G{08DBEFD7-6A19-4DCE-A533-5BDBB93683C8}#1.2#0#..\..\..\..\..\Windows\SysWOW64\Comdlg32.oca#Microsoft Common Dialog Control 6.0 (SP3)
Removing this line seems to resolve the problem. Why does this resolve the problem?
I have used Winmerge to compare yesterdays revision of the project (which does not have the problem) to todays revision of the project (which does have the problem). The only difference is the reference in the original post in the VBP file.
I would assume that someone installed the development version of this control on a different machine and then set a reference to it. When you try to open the project on your machine the reference fails. Or the control was uninstalled. It seems that the project was not using the reference and that it can be safely removed as it will still compile without the reference.
However, I have seen vb6 actually remove non-licensed controls from the form in question in this situation. So it may be that you can now compile because the form is missing a component that was there previously. Have you checked that frmMain has not changed, both the .frm and .frx files?
I have a blocking error in vb 2008( windows forms application ).
In my project I used excel 2010. I have added the statement 'Microsoft.Office.Interop.Excel' in my program. I got a error that it is not a namespace member.
I learned that I need go add reference of a library component and so I downloaded and installed primary interop assembly service for excel 2010. Even now if I add my reference I get no change in components.
Still the same error.
help please.its urgent
Have you Office installed?
If not, you cannot use Interop.
If you have installed Office you should add a reference:
Go to my project -> references -> add -> com -> microsoft.excel.12(14).library. Then it should work. The 14 denotes that, depending on your version, the exact number will vary.
If you have no excel installed, you could try EPPLUS: http://epplus.codeplex.com/
It is a great library to read / write xlsx files, much more quickly and more comprehensible than interop.
How are those files constallated and where can I find more information about them?
It is recent version of Visual Studio I'm using.
The different system assemblies live in the Global Assembly Cache (GAC).
You do not normally need direct access to these files - see How to: Add or Remove References By Using the Add Reference Dialog Box on MSDN.
The assemblies that are in the GAC will appear on the .NET tab of the dialog.
To use a namespace directly in the class (so you do not need to fully qualify it), use the Imports statement.
I have a native app that has an .OCX file that needs to be registered for it to be used in a .NET application.
Now currently there's different versions of this .OCX on the machine. Can someone please explain how this can affect the registration of this new (updated) .OCX file registration?
And how does my .NET app know which object to create from which .OCX file?
COM servers are required to change their CLSID guids if their interfaces are no longer compatible. So if your supplier did it right, you should be able to register both of them and get the right one when you use the right reference in your project.
Like any rule, this one got violated often and is presumably the reason you started this question in the first place. The back-up plan is to use registry-free COM, you write a manifest and add it to your program so it always uses the local copy of the COM server DLL instead of the one that was registered. Find out how to do this by googling "regfree COM", I see many relevant and useful hits at the top.
I believe COM class registrations include the entire path to the "server" providing the COM component. If the two versions of the .OCX have different class GUIDs, then there should be no issues.