I have some code that uses a 3rd-party lib (ArcObjects) exposed by COM. So for instance there´s the IGeometry-interface.
IGeometry geometry = GetGeometry();
Now when I want to look at the objects members I open a QuickWatch:
I´ve read several issues that all point to the "enable native code debugging"-option in Visual Studio 2015. I´ve already enabled that option to no avail.
How can I get the debugger to expose the members of the COM-object?
EDIT: When working with VS2010 and .NET 3.5 this works:
Enabling unmanaged debugging can only have a useful side-effect if you also have the PDB and the source code for the component. You don't, vendors of these kind of components don't disclose it. The only reason you can see anything at all is because you let VS generate the interop assembly for the COM component. Which converts the declarations in the type library for the component into equivalent .NET types. Like IGeometry, most probably actually a C++ class under the hood.
Which is the big difference between the top view and the bottom screen-shots. Starting with VS2010 and .NET 4.0, this interop assembly is no longer needed. Called "type embedding", in general a highly useful feature, it avoids the need to deploy the PIA for a component. A very big deal in particular for Office interop.
Type embedding aggressively removed types and members that are not used in the source code. What is left is embedded into your final assembly, thus removing the need to deploy the interop assembly or PIA. Or in other words, you can't see IGeometry.Envelope back in the debugger because your source code doesn't use the property. It got stripped by the type embedding plumbing.
That is easy to fix. Select the COM reference in your project's Reference node and set its "Embed Interop Types" property to False. You can leave it that way after testing, don't forget then to also deploy the interop assembly.
As suggested in the comments I posted that question on gis.stackexchange.com also, from which I quote our solution:
In Visual Studio under Tools-->Options-->Debugging enable the option
"Use Managed Compatibility Mode".
Related
I'm building a C# add-in for SolidWorks, and I can't seem to find any definitive answer as to which files to reference in my project. I've used .DLLs in previous projects, and .TLBs in this one. For SolidWorks specifically, I liked TLBs better because the definitions of functions are provided with their actual return types instead of just dynamic so that I don't have to look it up in SolidWorks' docs. However, in all the videos and sites I've found, nobody seems to be using TLBs. SolidWorks' docs site isn't so helpful as it's all over the place and explanations are very lackluster.
Docs for Early and Late Binding says that TLBs are just for early binding.
This page here says that TLBs are for C++/CLI, VB .NET, and VBA. No mention of C#. This one other page (can't find it right now) showed code using TLBs instead of DLLs, but everybody else seems to be using DLLs.
What am I actually supposed to use? What are the differences (for SolidWorks and for general COM stuff) other than early/late binding and dynamic?
When you are adding tlb, it get converted to the interop dlls behind the scenes so it is almost the same as adding dlls, but there is one major difference. Those interops would not have strong names so you might have troubles with compatibility in future, unlike the dll interops which are strong signed.
I would also recommend to not use 'Embed Interop Types' option. In this case you will not have dynamics and can use I-versions of methods to access type safe versions of APIs.
As a summary: add interop dlls (from .NET tab), set 'Embed Interop Types' option to False for all SOLIDWORKS interops
I'm trying to add Windows/System32/Shell32.dll DLL to my project. The issue is, it copies the reference to the directory! Since this is a windows file, it shouldn't have to come with me if I were to deploy my application.
I have tried stopping it from copying to the directory, tried looking for how to embed the resource in the application and even added reference paths to System32. It seems so much more challenging than the program just using the local DLL from the system...
What can I do?
Shell32.dll is a COM component. You should not get a copy of it in your project. What you get instead is Interop.Shell32.dll. Which is a .NET assembly, not a copy of Shell32.dll. It contains the COM interface and class declarations, converted from the type library definition inside Shell32.dll to friendly .NET declarations that the CLR knows how to easily handle.
This is an optimization, it avoids having to make the conversion at runtime. Which is expensive, subject to various options (check the MSDN docs for Tlbimp.exe) and may easily fail because there is no general requirement that the type library is also available on the target machine.
You must deploy Interop.Shell32.dll to the target machine, just like you do with any .NET class libraries you'd use.
Do note that this interop library is no longer needed on .NET 4 and VS2010. Which acquired the "Embed Interop Types" feature. In other words, instead of keeping the interop types in a separate assembly, the C# and VB.NET compilers can now embed them in your program. Very highly recommended, just set the option to True in the Properties window view of the Shell32 reference.
In Visual Studio, when adding one reference to the project, the properties window has an option Embed Inteop Types, should we set it to True or False? What's the difference?
Since we have a lot of projects, among some of them, reference was set to False, others were set to True, it is totally mess up. And the bulid server also have the same warnings:
What does “reference was created to embedded interop assembly” mean?
So we plan to change all the Embed Inteop Types to False, what risk would we get?
This option was introduced in order to remove the need to deploy very large PIAs (Primary Interop Assemblies) for interop.
It simply embeds the managed bridging code used that allows you to talk to unmanaged assemblies, but instead of embedding it all it only creates the stuff you actually use in code.
Read more in Scott Hanselman's blog post about it and other VS improvements here: CLR and DLR and BCL, oh my! - Whirlwind Tour around .NET 4 (and Visual Studio 2010) Beta 1.
As for whether it is advised or not, I'm not sure as I don't need to use this feature. A quick web search yields a few leads:
Check your Embed Interop Types flag when doing Visual Studio extensibility work
The Pain of deploying Primary Interop Assemblies
The only risk of turning them all to false is more deployment concerns with PIA files and a larger deployment if some of those files are large.
I noticed that when it's set to false, I'm able to see the value of an item using the debugger.
When it was set to true, I was getting an error - item.FullName.GetValue The embedded interop type 'FullName' does not contain a definition for 'QBFC11Lib.IItemInventoryRet' since it was not used in the compiled assembly. Consider casting to object or changing the 'Embed Interop Types' property to true.
I need to late bind to a 3rd party VB6 COM object in a 3.5 C# application (to avoid version dependencies that we currently have). The dll that was provided is not consumable in most non-latebound ways due to some bug that causes errors when we try to consume it normally. Currently, we are using a custom VB6 wrapper that makes things VERY version specific, however I have found that I can use late-binding to access properties and methods. Now, I am trying to late-bind to events, however everything I have read says that I need to inherit from the COM wrapper's interface to create the event sinks that are needed. Here is one such article.
So, my question is whether it is possible to perform late-bound event handling without having any reference to the dll at compile time?
UPDATE
Here are the errors I have with the VB6 wrapper (Which is still being actively updated).
In OleViewer, I get
Could not decompile selected item Error loading type library/DLL.
TYPE_E_CANTLOADLIBRARY ($80029C4A)
In Visual Studio I get:
Could not determine the dependencies of the COM reference
"3rdPartyDLL". Error loading type library/DLL. (Exception from
HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY))
From here:
I found that the problem is caused when the IDL contains an importlib
to another project's .tlb typelib.
This seems to create a dependency between one dll and the other.
If dependant dll is missing OLEView refuses to display the dependent
dll, which also manifests itself by not allowing #import from C++
code.
Therefore I would look carefully at the COM dependencies of the DLL in question and make sure they are all registered as well.
It also goes on to add:
...because both dlls are co-dependent,
components from each interact (via interface declarations on method
signatures) and use #import from each others typelib.
Therefore, unless both target dlls are present, neither can be
rebuilt. As you can imagine, this causes a terrible problem when you
try to completely rebuild the project's from scratch.
I've experimented with separating the interface definitions into
smaller IDL files...
Edit: here's a recent example of this problem coming about (I believe). I had a C# library exported to COM. Modifications to that library were made which changed the interface of several classes, but the library GUID was not changed. Also see here about risks of AutoDual which was in use.
Here's the odd part - the VB6 DLL was rebuilt referencing the modified C# DLL. It compiled fine. no errors. But its typelib was corrupt - OleView couldn't open it, failing with TYPE_E_CANTLOADLIBRARY. Changing the C# DLL GUID was necessary to get the VB6 DLL recompiled successfully.
Clearly a pitfall of VB6 / C# interop.
The problem is most probably caused by the platform you are using. I just had a similar problem yesterday. Make sure that you are setting your project platform to x86 / x64 when you are late binding a x86/x64 COM type library.
The same applies to oleview. Use the x86/x64 version to view x86/x64 type libraries. (Possibly you need to install the x64 Windows SDK if you are on an x64 system to get the correct executeable).
Since version 3.0, .NET installs a bunch of different 'reference assemblies' under C:\Program Files\Reference Assemblies\Microsoft...., to support different profiles (say .NET 3.5 client profile, Silverlight profile). Each of these is a proper .NET assembly that contains only metadata - no IL code - and each assembly is marked with the ReferenceAssemblyAttribute. The metadata is restricted to those types and member available under the applicable profile - that's how intellisense shows a restricted set of types and members. The reference assemblies are not used at runtime.
I learnt a bit about it from this blog post.
I'd like to create and use such a reference assembly for my library.
How do I create a metadata-only assembly - is there some compiler flag or ildasm post-processor?
Are there attributes that control which types are exported to different 'profiles'?
How does the reference assembly resolution at runtime - if I had the reference assembly present in my application directory instead of the 'real' assembly, and not in the GAC at all, would probing continue and my AssemblyResolve event fire so that I can supply the actual assembly at runtime?
Any ideas or pointers to where I could learn more about this would be greatly appreciated.
Update: Looking around a bit, I see the .NET 3.0 'reference assemblies' do seem to have some code, and the Reference Assembly attribute was only added in .NET 4.0. So the behaviour might have changed a bit with the new runtime.
Why? For my Excel-DNA ( http://exceldna.codeplex.com ) add-in library, I create single-file .xll add-in by packing the referenced assemblies into the .xll file as resources. The packed assemblies include the user's add-in code, as well as the Excel-DNA managed library (which might be referenced by the user's assembly).
It sounds rather complicated, but works wonderfully well most of the time - the add-in is a single small file, so no installation of distribution issues. I run into (not unexpected) problems because of different versions - if there is an old version of the Excel-DNA managed library as a file, the runtime will load that instead of the packed one (I never get a chance to interfere with the loading).
I hope to make a reference assembly for my Excel-DNA managed part that users can point to when compiling their add-ins. But if they mistakenly have a version of this assembly at runtime, the runtime should fail to load it, and give me a chance to load the real assembly from resources.
To create a reference assembly, you would add this line to your AssemblyInfo.cs file:
[assembly: ReferenceAssembly]
To load others, you can reference them as usual from your VisualStudio project references, or dynamically at runtime using:
Assembly.ReflectionOnlyLoad()
or
Assembly.ReflectionOnlyLoadFrom()
If you have added a reference to a metadata/reference assembly using VisualStudio, then intellisense and building your project will work just fine, however if you try to execute your application against one, you will get an error:
System.BadImageFormatException: Cannot load a reference assembly for execution.
So the expectation is that at runtime you would substitute in a real assembly that has the same metadata signature.
If you have loaded an assembly dynamically with Assembly.ReflectionOnlyLoad() then you can only do all the reflection operations against it (read the types, methods, properties, attributes, etc, but can not dynamically invoke any of them).
I am curious as to what your use case is for creating a metadata-only assembly. I've never had to do that before, and would love to know if you have found some interesting use for them...
If you are still interested in this possibility, I've made a fork of the il-repack project based on Mono.Cecil which accepts a "/meta" command line argument to generate a metadata only assembly for the public and protected types.
https://github.com/KarimLUCCIN/il-repack/tree/xna
(I tried it on the full XNA Framework and its working afaik ...)
Yes, this is new for .NET 4.0. I'm fairly sure this was done to avoid the nasty versioning problems in the .NET 2.0 service packs. Best example is the WaitHandle.WaitOne(int) overload, added and documented in SP2. A popular overload because it avoids having to guess at the proper value for *exitContext" in the WaitOne(int, bool) overload. Problem is, the program bombs when it is run on a version of 2.0 that's older than SP2. Not a happy diagnostic either. Isolating the reference assemblies ensures that this can't happen again.
I think those reference assemblies were created by starting from a copy of the compiled assemblies (like it was done in previous versions) and running them through a tool that strips the IL from the assembly. That tool is however not available to us, nothing in the bin/netfx 4.0 tools Windows 7.1 SDK subdirectory that could do this. Not exactly a tool that gets used often so it is probably not production quality :)
You might have luck with the Cecil Library (from Mono); I think the implementation allows ILMerge functionality, it might just as well write metadata only assemblies.
I have scanned the code base (documentation is sparse), but haven't found any obvious clues yet...
YYMV