Is this dll a part of visual studio tools for office or Microsoft Office Word s/w?
PIAs are just intermidiate files that are used in transferring/marshalling calls between mananged/unmanaged boundaries. For example, they are used to convert managed types to unmanaged ones. You can generate them on your own without VS involved. Under the hood, VS uses the same tools to generate them when you add an unmanaged references (COM).
You can read more about PIAs in the Office Primary Interop Assemblies section in MSDN.
Related
I would like to obtain a collection of all .cs files in a solution for analysis from a Visual Studio Extension. There are a couple methods of doing this on SO, but these are outdated and clunky. Specifically, they utilize old COM compatibility libraries, and require casting and inspecting GUIDs stored as strings.
How do I list all the projects in the current solution using EnvDTE?
Enumerate all files in current visual studio project
Visual Studio Extension get all classes and interfaces metadata
Any method which also gives access to some parse tree would be especially useful (in my case).
I have a DLL generated from Visual Studio 2010, but I need to link it to a 2008 project that needs to remain 2008 for various other reasons. Anyone run into similar trouble or have advice?
VS2010 is .NET 4.0
VS2008 is .NET 3.5
So the answer for your question is NO because if the dll is making use of any of the specific .NET 4 features, it wont get executed in your 3.5 environment. Also it may happen that the assembly mapping is different in both the .NET version and that may become one of the reason for the 4.0 dll not getting executed in 3.5 env.
I am not sure, but you may look at COM Interop features. May be it can help you in achieving what you want. But it would be too messy !!
Dynamic-Link libraries (DLL) are an integrated part of the Windows platform from its very beginning. DLLs allow encapsulation of a piece of functionality in a standalone module with an explicit list of C functions that are available for external users. In 1980’s, when Windows DLLs were introduced to the world, the only viable option to speak to broad development audience was C language. So, naturally, Windows DLLs exposed their functionality as C functions and data. Internally, a DLL may be implemented in any language, but in order to be used from other languages and environments, a DLL interface should fall back to the lowest common denominator – the C language.
http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL
Standardized C style interface, should be ok, though that pertains only to non managed C++.
I haven't done COM in over 10 years so I was wondering:
When I utilize a 3rd party COM based SDK by importing its TLB file -- is it their responsibility to release a version of TLB for each version of visual studio I use their SDK with? or is TLB a "flat" binary file that fits all versions of visual studio?
The type library format is standardized and independent of any tool that reads it, including Visual Studio. Tools use ITypeLib and ITypeInfo to read one, implemented by Oleaut32.dll
I have a C# project in Visual Studio 2005 that is referencing a few COM libraries. When I build it errors like this are thrown:
Referenced assembly 'assemblyName' does not have a strong name.
Now, I used to reference COM assemblies in Visual Studio 2003, and it would automatically sign the Interop wrappers. All I had to do was set the setting 'Wrapper Assembly Key File'.
I tried finding a similar setting in Visual Studio 2005, but I couldn't find any. So I was wondering if there's any equivalent way of strong naming COM Interops in Visual Studio 2005 and getting rid of the above error.
It looks like it was already answered in "Where is the Wrapper Assembly Key File setting in VS 2008?" question.
Instead of using Visual Studio you could use Tlbimp.exe and
Aximp.exe to generate the Interops. Tlbimp.exe has options for signing.
I have used them to be generate an Interop file for each different version of the same COM component in my application. The COM components are vendor supplied COM components used for accessing data points in mass spectrometry files and the COM interface change from time to time as new versions of the vendor software is released. The application can then decide at runtime which Interop to use in order to match what version is installed on the computer where the application is installed.
The BAT file I use for generating the Interops is online.
I have installed the 2007 PIA and repaired my Office 2007 installation.
Still, when I add a reference to the Office 12 Object Library in VS2005, I only see Office.Core and cannot add an 'imports' statement for Office.Interop
I have checked that Windows\assembly\gac\ has got the interop dlls.
With the PIAs installed, you have to add a reference to the corresponding COM library - instead of generating an automatic interop, the PIA will be used instead.
To quote Microsoft's documentation
For Microsoft Office applications that do not have projects in Visual Studio Tools for Office, you must add a reference to the appropriate application or component to your project manually. Adding a reference to the component references the primary interop assembly, if the assembly is installed in the global assembly cache. Office applications and components are accessible from the COM tab of the Add Reference dialog box.
Add a browse reference. You have to ship the PIA dll to get any benefit out of it anyway.