Hide the referenced assemblies in the weborb console. Is this possible? - weborb

Hide the referenced assemblies in the weborb console. Is this possible?
(weborb.dll in example)

I have asked this a year ago to the midnight coders and then it wasn't possible. I really think it still isn't.

You can deploy your referenced assemblies to the GAC. This effectively hides them from WebOrb, while permitting them to function for the deployed .dlls.
This does assume that you are permitted access to the GAC, which is not really a given.

Related

WFA won't open on other computers

I recently programmed a Windows Form Application on one laptop, however, when I attempt to run the executable on my client's PC it won't open. There are no error messages generated, it just won't open.
The only thing in use that wasn't built into VS2015 was Telerik UI for winforms and the application is a standalone exe.
Any suggestions?
I finally got this sorted a couple of days ago. After a LOT of fiddling about I realised that it was indeed to do with the references. After consulting the Telerik Documentation (as Chris suggested) I realised that, indeed, the dlls were stored in the GAC (something I'd never heard of) and not actually automatically packaged with the software. So I editted the program file options so that they were included and problem solved! Thank You all for your help and sorry the original question was so badly written, I had no idea what data it would have been relevant to include

VSTO2010: Reference to class 'RibbonBase' is not allowed when its assembly is linked using No-PIA mode

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".

When Should Namespaces Become Their Own, Independent Class Libraries?

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

Zune API ZuneCore.dll

I noticed the other day that the Zune PC Software exposes a type library (ZuneCore.dll). It seems to be related to the WMPLib API in some way but I can't figure out how to use it either from VB6 or C#.
Has anybody tried this and had any luck?
Dave
May be an old question, but this link might help: http://zunelcd.codeplex.com/ If you download the source for this project one of the class libraries is a decent API for communicating with the Zune Software.
i just found out about this -> http://soapitstop.com/blogs/fleamarket/archive/2008/03/03/read-the-zune-collection-in-net-from-zune-s-own-api.aspx but it seems a bit outdated Initialize method now takes some parameters and i dont know what to put there!
Try adding a reference to it from a .NET project in Visual Studio. Perhaps this namespace will appear magically: MicrosoftZuneLibrary

How is shared dll (GAC ) loaded to memory and used in comparison to private dll

I'd like to point out that I know how to add/remove assembles to/from GAC. What I am asking for is if someone could explain me how does it work from the technical point of view. What's the point in putting dll's there - from the point of view of saving the resources.
Kind Regards
pk
The point of putting things in the GAC is so that multiple applications (even from different vendors) can access the same assembly. There is then one location where it can be updated and all applications which can properly access that version can use it. You also know that all assemblies in the GAC are digitally signed, so you know where the code came from (MS for example).
As far as loading into memory. Each application will have to load it on it's own.
This question gives a good argument for not using the GAC where you can avoid it.
And this question gives a couple of links to GAC demystification articles which may help your decision.