I'll explain what i'm trying to do (and why) first and then get more into the details.
I'm trying to get Registration Free COM activation working in the context of a language that is compiled JIT. I use Reg-Fre COM because i would like to avoid having to register my COM component and would like this application to be installable without administrative rights.
The JIT compiler is the main executable is signed and contains an embeded manifest. Latest versions of Windows prefer the embeded manifest over an external one, by default (it was the opposite on Windows XP).
Since the JIT is signed, i cannot extract/modify/update it's manifest without breaking the signing. Also, this would introduce complexity in the maintenance of our application (always making sure we embed a new manifest). And there's are also the legal implications of modifying a program for which i don't own the rights.
So, my idea was to try to get the WinSxS activation going thru a Win32 wrapper library for which i would provide a manifest that lists the dependencies. As a proof of concept, i decided to make a simple VB6 app, a C++ Wrapper Library and two COM library (1 in .NET and 1 in VB6).
The wrapper contains 3 methods, one that calls the VB6 COM, one that calls the .NET COM and one that returns a simple string.
As long as everything as my COM are registered, it works, of course.
If i unregister them, provide manifests for the COMs and add them as dependencies to the main executable's manifest, it works.
If i unregister them, provide manifests for the COMs and the C++ Wrapper and add the com as dependencies for the C++ Wrapper and then add the C++ Wrapper as the only dependency in the main executable's manifest, it works.
If i delete my main executable's manifest, the COM calls stop working but the simple string method still works.
Please note that for all my tests, i run a Powershell script that changes the Modified Date of all my files, making sure to trip the activation context cache (manifest).
From there, i started debugging using SXSTrace.exe and setting the COMPlus_LoadLogDir variable. I found out that if my manifest is external, it never gets taken into consideration. I also found out that if i embed it in the .DLL, sxstrace shows it is found, parsed and that the dependencies are found, their manifest found and i get the usual successful context activation lines in the log.
INFO: Parsing Manifest File C:\RegFreeComWrapper\bin\vbCom.MANIFEST.
INFO: Manifest Definition Identity is vbCom,type="win32",version="1.0.0.0".
INFO: Parsing Manifest File C:\RegFreeComWrapper\bin\netCom.MANIFEST.
INFO: Manifest Definition Identity is netCom,processorArchitecture="msil",version="1.0.0.0".
INFO: Activation Context generation succeeded.
End Activation Context Generation.
However, even tho the log says that, my COM calls still dont go thru.
When the call goes thru for the .NET COM call, i get some output in the COMPlus_CLRLoadLogDir configured path.
In this case, i don't get any output.
As soon as i add the manifest that only lists my C++ Wrapper as a dependency to my main executable, everything starts working again. I get a similar output from SXSTrace, but now the COM call works. As mentioned, in all cases, the C++ Wrapper's simple string method works. Meaning that even tho i have no manifest from my main executable, it can still find my .dll and call it.
Seems like the COMs don't work if i dont have the full manifest chain:
Application.Manifest > Wrapper.Manifest > COMs manifests
So, two things here...
1. Is the thing i'm trying to do even possible? (Having dependencies listed only in the manifest of a DLL that belongs to me, without touching the main executable's manifest)
2. If it is possible, i'm probably only missing a small thing to get everything going... what is it ? :)
I can provide all my code/executable as examples, should someone be interested in trying stuff with em.
Got it working!
I modified my C++ Wrapper to use the Activation Context API and force a context activation using 'ActivateActCtx'
http://msdn.microsoft.com/en-us/library/aa374151(v=vs.85).aspx
I wrapped my code with their example's code and made sure to reference my manifests and now all is working fine. No manifest on my main executable!
Related
My goal is to expose a .NET 6.0 library to COM, in order to use it from VBA in MS Access. And to use the manifest approach rather than using the registry.
Got article "Exposing .NET Core components to COM" working, using their "COM server sample" example code.
This example however requires that a manifest file is present in the folder containing the executable. When using the COM object from MS Access we do not want to place the manifest file and other files in the MS installation folders.
The suggested solution is to create an Microsoft.Windows.ActCtx object and let that object create my COM object, using the Manifest property of the ActCtx object to specify the manifest file.
This is the part that continues to fail. actCtx.CreateObject("") gives an Invalid Cast exception, even without assignment of the result to a variable, hence it is an internal issue. No additional details, no information in the event log. Tried this in C# and from VBA.
I have a few questions:
Is ActCtx the way to specify the manifest path, or is there a better way to do this from VBA in MS Office?
The example uses a COM host, which seems to be some COM class / object factory, which in turn helps creating my COM object. As opposed to .NET Framework this COM host seems to be introduced for .NET Core; .NET 6.0 in my case. Is the COM host required? Is the simpler direct instantiation possible?
Does anyone has answers to these questions, tips, or even better: a working example?
Some progress but I am still not happy. Abandoned the ActCtx approach for a while and tried to create the COM server object of the sample directly in MS Access VBA. Added a reference to the com host, say COMServer.comhost.dll, as opposed to the implementation COMServer.dll. Created the object, simply with New. Error: class not registered. Performed a regsvr32 COMServer.comhost.dll and the sample works.
Although the sample works there are now again registry entries: the guid of the server class has been added to the registry. Regfree COM not achieved.
This is despite COMServer.comhost.dll looking promising. A tlb type library built separately and embedded in the .dll is seen by VBA: intellisense works and the object browser works. The manifest seems to be correctly embedded in the .dll too, and takes precedence over the manifest on disk.
The question remains how to avoid the regsvr32 step and make the solution working by just adding the reference to COMServer.comhost.dll, in MS Access VBA.
I'm using the GCE library in Go, along with go modules.
I'm finding that, while it happily compiles and runs unit tests, it's not resolving those types (e.g. compute.Instance) in the Goland IDE. I'm using 2020.2.
I first added this dependency by hand-coding (adding "google.golang.org/api/compute/v1" to my imports, and letting the module handler load whatever it needs). It added google.golang.org/api v0.50.0 to my go.mod file.
I've tried the old "Invalidate and Restart" approach, and it didn't do anything. I have another project where a different version of that module happens to be loaded, and it works fine on that one.
I've even tried a more nuclear version (Invalidate (no restart), close project, close IDE, delete the .idea directory, and delete the contents of ~/.cache/JetBrains). Still no dice.
FWIW my go module's version is go 1.15
You can navigate to the package sources by pressing Command/CTRL+Click on the import statement (or via External Libraries menu in Project View) and find compute-gen.go file and size limit warning. The IDE behaves as expected.
As a workaround, you can invoke Help | Edit Custom Properties... and add the following line idea.max.intellisense.filesize=8500000 (depends on the original file size), restart GoLand. Please, keep in mind that the IDE can be slow when dealing with large files even if they are not open in the editor.
You can read more about the idea.properties file here.
In the documentation for app-indexeddb-mirror at https://elements.polymer-project.org/elements/app-storage?active=app-indexeddb-mirror there is a section I've copied below. I think I'm running into an error because the indicated file isn't loading, but I'm not sure how to fix the issue. Do I add a reference in staticFileGlobs in sw-precache-config.js or somewhere else?
In order to ensure that operations on IndexedDB block the main browser thread as little as possible, app-indexeddb-mirror relies on a WebWorker to operate on its corresponding IndexedDB database. If you are vulcanizing or otherwise combining your source files before your app is deployed, make sure that you include the corresponding worker script (app-indexeddb-mirror-worker.js) among your deployable files. You can configure the path to the worker script with the worker-url attribute.
The error I'm getting:
GET https://example.com/src/common-worker-scope.js?https://example.com/bower_components/app-storage/app-indexeddb-mirror/app-indexeddb-mirror-worker.js net::ERR_INTERNET_DISCONNECTED
It's a follow-up from this.
Windows Phone 8 C# project (MyApp), migrated from WP7.1. I've added a native Windows Runtime component library (AppLib) to the solution, created a reference. There's a public sealed ref class (MyClass) in it. There's a reference to it in the C# code (in OnLoaded of the main XAML page). The whole thing builds - meaning the metadata of the component is being generated.
When I'm trying to run on the emulator, the project fails with the exception or type BadImageFormatException with the following message:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
The error typically pops up when you try to mix CPU types in .NET.
The active platform is "Mixed platforms". In the Configuration Manager, it's configured to build MyApp for "x86" and AppLib for "Win32". In a vanilla freshly generated project that runs fine, the config is identical.
Question - what's wrong with that configuration? What do I need to check?
EDIT: I've added a second, blank C++ library to the solution - TestLib. This one loads and works as expected.
EDIT2: excluded everything from build in AppLib - it works. Now I'll be adding lines one by one, see which one causes the issue...
Totally my fault. When I changed the namespace of AppLib (see the linked question), I've left one little declaration in the library in a MyApp namespace.
The error is still misleading. I'd delete the question, but since the error message is sure to send someone on a wild goose chase with build CPU type and whatnot, let it remain.
Shouldn't a Windows Phone library be built for ARM in most cases? Have you had a chance to watch the "Windows Phone 8: Using C++ in your Applications" session from last week's //Build/ conference? That might include some answers.
I have a couple of test files written in my DSL in my tests plugin/project. Most of the tests use inline multi-line strings and Xtend but in four cases, I need to test code which does some magic with URLs and the classpath, so I really need resources in the classpath for that.
Since loading the resources only works when the extension is correct, I can't give the files a fake extension.
Now my problem: My DSL also has a code generator. This means that eventually, I end up with a couple of generated files in places where I can't have them (they don't compile, for example, and one even contains an error to test error handling when information is split across several files).
I can't disable the Xtext nature because the tests project uses Xtend so for these files, I do need code generation.
Since the generator runs inside Eclipse (I have the DSL plugins installed for other projects), there is no way to override the code generator in Guice.
How can I disable the code generator in this case?
There is a simple way to achieve this:
Open the properties of your project
Expand the entry for your DSL
Select "Compiler"
Select "Enable project specific settings"
Disable/deselect "Compiler is activated" under "General"
If you don't have a properties entry for your DSL:
Add this fragment to your .mwe2 workflow file:
fragment = generator.GeneratorFragment {}
Regenerate your projects
Merge the new code from plugin.xml_gen into plugin.xml both in the base and the UI plugins.
The interesting parts are the two extension points org.eclipse.ui.preferencePages and org.eclipse.ui.propertyPages