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.
Related
I have an OCX without documentation and need to use it.
I've figured out most of the stuff, but, is it possible to monitor all the calls and arguments made by one software to that OCX?
I've tried ProcessMonitor, APIMonitor and none of them give me that information.
I haven't tried it myself, but WinApiOverride seems to support COM object calls monitoring:
http://jacquelin.potier.free.fr/winapioverride32/doc/com.htm
This is a pretty advanced tool, however, and you'll likely have to spend some time adding rules for your specific COM classes.
Through COM, one can potentially gain absolute control over a target system. For example: using javascript's ActiveXObject object in IE, one can create certain objects which were designed to have direct access or interaction with system properties and files. One would think common sense dictates users disable ActiveX features in IE immediately after installing the browser to ensure their system is protected while surfing the net, or at least paying close attention to which websites they permit. But, I doubt many average PC users know how or why to do this, or just get tired of mirco-managing it over time. I think any PC user or admin my COM class caters to would greatly appreciate not having to deal with that. Thankfully it looks like IE versions come packaged with ActiveX disabled by default nowadays.
I've built a very versatile COM class library in VB. I didn't intend for it to be callable from any website, but that feature is just part of the COM platform. I'd like to prevent the library from being called from IE unless the website is on a white-listed domain to proactively protect the user (and ultimately their entire intranet) from harm from malicious websites. What would be the best method in VB.Net to tell which application called my DLL, to be able to tell if it was called from any command or process originating from IE? And, what domain called my dll?
Edit: I believe this might be a duplicate. See: Calling Assembly to get Application Name VB.NET
System.Environment.GetCommandLineArgs()(0) gets me the calling application path. With this info, I can compare it to a black/white-list of applications. Problem solved for now.
Don't mark the control as Safe for Scripting.
Default security settings will not allow such controls to be scripted.
Self-answer, and possibly duplicate, I suppose. See System.Environment.GetCommandLineArgs()(0) from Calling Assembly to get Application Name VB.NET
In this case, the class never was marked as safe for scripting and the intent was already never to mark it safe. The issue was how to obtain the calling application info so I could add additional security measures in case those which the calling application had were not enough.
I have trouble understanding XPCOM. How is it different from COM? What makes it cross platform?
Is it a framework with a set of libraries that you can use to do some jobs?
Also, does Component Object Model means every functionality is implemented in component so we can use it without knowing the detail implementation?
Can you someone help me understand this please?
Thanks,
Chan.
I have trouble understanding XPCOM.
How is it different from COM?
XPCOM is Mozilla's own, cross-platform (hence the XP bit) version of COM.
What makes it cross platform?
It is implemented in a library that has been ported to many platforms by contributors to the Mozilla open-source project. You can build it or download a binary for any platform that you wish and, in the extremely remote possibility that you want to use it on a platform that is not already supported, it should be straightforward to port it yourself.
Also, does Component Object Model
means every functionality is
implemented in component so we can use
it without knowing the detail
implementation?
Yes, spot on. The idea is for a language-independent framework that enables different components to communicate and interact, without requiring any special knowledge of the language that any particular component is implemented in. So javascript code can call C++ code, for instance.
This is achieved by components publishing well-defined interfaces, using a language called IDL (or, in XPCOM's case, XPIDL). These interfaces make use of well-defined types with mappings in each of the supporting languages. Every interface inherits from a common base interface, which provides standard methods for reference-counting and type-inference (called IUnknown in COM and nsISupports in XPCOM).
Can you someone help me understand
this please?
In terms of online resources, there are dedicated areas on both the MSDN (for COM) and the MDC (for XPCOM). If you want to really understand the motivation for COM and why it is the way it is, I recommend picking up Don Box's Essential COM. And of course, if you have any specific questions that need answering, you can always come here to ask them. :)
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".
I have an application that uses many different .NET managed DLL's as objects (each DLL implements a common interface). Each DLL also has a version number in the file name.
Suppose I create the object "Shape~01.dll." The application will use that DLL but it can't be replaced while the application is running. So, if I want to "upgrade" the shape dll I have to create "Shape~02.dll" and the application has to dynamically search for and load the newest dll everytime a shape is created and/or the user has to restart the application. It get's worse, each dll depends on the main .exe thus has to be rebuilt with the main .exe.
Is there an easier method to have dynamically "replaceable" objects?
Well, this isn't the best solution (still thinking about it), but you can unload dll files which will allow them to be replaced. That might be a quick stopgap solution until you come up with a better idea.
You don't mention which language/platform you are trying to accomplish this in, so I will answer for the .NET Framework.
If you want to do it the hard way look at Shadow Assemblies, this is the method that ASP.NET uses to keep the site updateable though it is using the files.
For a much easier method look at the new System.Addin namespace, this uses Shadow Assemblies under the hood and should do what you want.
Instead of polling when creating an object, why not just request notification from the system when the file system changes?
The class is System.IO.FileSystemWatcher in.NET.
For native code there are a few ways to watch a folder, but IANAND (I am not a native developer ;).
Although having said those things, you probably want to rethink the reason you need to change your objects so frequently, because it will probably take a lot of work to make it work.
You used the dynamic tag, so maybe you should try a dynamic language? :)