When I try to compile my VSTO Outlook addin, I get this error:
Reference to class 'RibbonBase' is not
allowed when its assembly is linked
using No-PIA mode
Can't seam to find a solution to it online.
Any idea?
Thanks!
Mojo
Certain COM libraries, including this one, do not support No-PIA mode.
Change Embed Interop Type to false in the properties of the reference.
I can't swear that what I'm about to offer would fix the RibbonBase issue, but I received exactly the same error message with respect to a class I was trying to use in Access, and found myself reading this question & answer, so I'd like to offer my solution as I suspect strongly that it might also fix the RibbonBase problem.
The issue is one of referencing a CLASS rather than an Interface. If you search for "is not allowed when its assembly is linked using No-PIA mode" in http://msdn.microsoft.com/en-us/library/h8c469ey.aspx, you can see where I get this from.
It kind-of makes sense - I can see that making the interfaces available gives a better object design (by separating interface from implementation) and would also reduce the meta-data required.
In Access, I was trying to reference ControlClass, and when I switched to using just "Control" (it's interface) then all worked fine for me.
From what I've read, I believe that SLaks solution, while it will undoubtedly work, it will require the Interop assemblies to be instelled on the machine that the solution is deployed on, where as switching to an interface (if possible) then allows you to deploy without the Interop assemblies. For me, that makes my suggestion more attractive, if it could be applied in the case of "RibbonBase".
Related
I'm working on a Solidworks Addin using VB.NET that utilizes the Solidworks API and CAMWorks API.
Basically, Solidworks has integrated a free version of CAMWorks dubbed "SolidworksCAM". The API dll reference for CAMWorks and SolidworksCAM are different, each with a unique GUID, but maintaining the same simple name of "Interop.CAMWorksLib.dll". The API functions are 100% the same, just each software ships with a different GUID for their API. This GUID ties back to the COM assembly loaded in Solidworks, so if Solidworks has SolidworksCAM loaded and my addin is complied with the CAMWorks API reference it will fail to retrieve the COM object.
How can I achieve compatibility between these two APIs without having two projects? Is it even possible? Thanks!
Whenever I post a question to a board it seems like I always solve it soon after.
For future reference, I used Reflection to dynamically load the Dlls. Below is some more detailed information.
I put the Dlls in two different folders in my project and set them to Copy. I then used Assembly.LoadFile to load the dll and get its assembly. I used this assembly to get the constructor class "CWAppClass" and fed its type into Activator.CreateInstance to get an instance of the main CWApp class. This way you can use whichever one doesn't error. Thanks for the help!
After taking advice to not use LoadFile(), i have found that there is a method in the Solidworks API that allows you to do this. By using Sldworks::GetAddInObject you can get the addin object for whichever addin you choose. Then you can use the CAMWORKSADDINLib to interact with this. Thanks for the suggestion, this it the perfect solution for my problem.
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
With the inclusion of Microsoft Fakes in Visual Studio 11, I thought it would be worth to look into again, since I did not find Moles mature enough last i checked. The documentation is still sparse, but I cannot find any reference to mocks, i.e. the ability to set up and verify expectations on the faked objects.
Does anyone know if this is currently included (as a feature in the library) or will be?
It is not included currently, but we are considering something in this area.
Although they are not included, you can use stubs to hack in the same behavior. In your stub you can capture whether the method was called and the parameters that were called. Of course, by the time you start doing that you're almost hand rolling your own mocks.
In the meantime I'd suggest Moq or RhinoMocks. I find the syntax simpler and I'm not a fan of the generated code that Microsoft Fakes uses anyhow. Try renaming a method on one of your fakes using a refactoring tool. It's not possible because your fake is a generated class, not an instance of the interface you are stubbing.
I could use a little advice on naming my assemblies
(ie. When to turn a logical naming convention in my
namepaces into its own DLL).
I recently downloaded an example project with a ton of
class libraries in it that almost exactly mirrored the
namespaces.
To date, I have been building one massive class
library - MyProject.DLL - and referencing it in my
project. This way, I only need one library and can
access all namespaces using it.
But, in the project I downloaded, there seems to
be a DLL for every namespace (and, in some cases,
subcategoreis within a namespaces. For example,
SomeProj.Web.Security has SomeProj.Web.Dll and
SomeProj.Web.Security.Dll).
I understand that having multiple DLLs can make
it easier to focus on particular areas of the project
(and, probably, updating the DLL withing the site
easier) but is there a best practice here?
Thanks in advance...
OK, this pretty much answers my question:
http://msdn.microsoft.com/en-us/library/ms229048.aspx
Since HTA applications are hosted within MSHTA.exe how does one provide a manifest? Plus I assume providing a MSHTA.exe.manifest could potentially break other HTA apps?
On Vista+, MSHTA.exe has an embedded manifest, which takes priority over external manifests, so your suggestion is not an option.
On XP/2003, yes, your suggestion would work, although it would be bad form, as is dropping files in System32 to modify the behavior of a system binary (especially make sure that any registration you put in the manifest are objects you are the only one to care about).
The proper solution, available on Win2003 and above, is to use the Microsoft.Windows.ActCtx object to instantiate your object given an explicit manifest reference.
For example:
var actCtx = WScript.CreateObject("Microsoft.Windows.ActCtx");
actCtx.Manifest = "myregfree.manifest";
var obj = actCtx.CreateObject("MyObj");
Perhaps, if this must work on XP as well, a path you may take is a combination of both solutions.
Edit: My answer is wrong, but I'll leave it here to avoid any similar wrong answers :)
If you question is can you access a COM object without registering it on the machine, then I think the answer is a tentative yes. However the work you would need to do would be substantial and would mean implementing a lot of the low level code that most development tools provide for you as a matter of course (Delphi, .NET, JAVA). You would need to interface with the dll directly (like you would a normal dll ), query its interfaces and call your methods.
If you have C, C++ knowledge, the way COM is accessed from these languages would give you some pointers.
Sorry I cant be of any more help.