this

Pritt & Whitney then. Rolls royce. Whatever.

@MathieuGuindon That'll be definitely awesome!

@FreeMan Precisely why you need to have those Boeing jet engines, preferably at least four of them on it.

oooorrrrr.... just hear me out, guys. You could just use an euclidean plane. Yeah, crazy talk, I know.

@FreeMan totally not like surreptitiously dropping off the Rube Goldberg machine on someone else's lawn, right?

Correct. This is a problem only for us wanting to make a mock of VBA types which is a different level from the persisting pointer to the ITypeInfo.

Unrelated: dscom now has a new version out. Time to say goodbye to olewoo & WiX. :)

@Greedo yes, that'd be the way to do it - you may want to cache the information how to find the ITypeInfo/ITypeLib, so that you can refresh the cached information easily while storing the harvested information within the class rather than persisting the pointer to the ITypeInfo/ITypeLib.

take a look at fafalone's tbShellLib. I think it's based on oleexp which already includes the interfaces.

@MathieuGuindon #ItDepends. Normally, .NET will never unload a type that's been loaded. Moq works around this problem by using dynamic proxy provided by Castle Windsor. However, Moq doesn't expose a method for invalidating the assembly

The 2nd issue is that the caching of the representing type for the purpose of mocking cause problems when running unit tests due to how types are cached in .NET. That's a .NET only problem and not applicable.

@Greedo There are two different issues. First issue is that a reference to a ITypeInfo coming from VBA project cannot be assumed to live beyond any design changes; you'll have to invalidate all the pointers to any ITypeLib/ITypeInfo whenever making design changes or experience the joy of crashing.

@Greedo TBH I never liked TLI and given that it's 32-bit only, I'd love to see a better replacement. May require some work, though.

@Greedo Yes, AIUI, it gives us the ability to inspect a project as if it was an external type library. We don't have the same visibility as we do with source code (only public symbols are available) but for the purpose of inspecting references to the protected projects, it would help give more complete information for the references to public symbols from the protected project.

@MathieuGuindon you speak as if they are not the same thing. :-p I think I sort of gotcha now - it's more that each will have their respective clients that will capture the events.

@MathieuGuindon I'm referring more to tracking the internal operations executed by the LSP server that the client may not be aware of? That is, if we are debugging and need a trace to flow through all the components?

wait a minute. If you want to have a end to end logging, the LSP would need to tell telemetry it's doing Y based on request X made from the client?

and as a bonus, open the way for RD to be on .NET whatever.

hopefully not too long before we can then start using it. looking forward to get rid of that dang rube goldberg machine. lol

FWIW, some update on the dscom PR.

@MathieuGuindon todo: add a cowboy hat ascii art for production

Gonna step out. TTYL!

yeah

and in this case, RD's inspections would just migrate over to tB.

the only thing is that we don't have code generators for ANTLR. More likely, Wayne may made compiler API available in future.

and with LSP processes, it'll be easier to work w/ tB IDE (which I believe is still LSP-based)

@mansellan no reason why RD can't be made to work with tB as well as VBx

will it come with cascading error messages, too? :-p

chatGPI, make me a telemetry server

@mansellan Yes true. will need the license, though to avoid the splash penalty for 64-bit builds. Still not sure how to handle it on AV.

@MathieuGuindon Yes, that's certainly one way to do it. If we do go down that road, tB can start out as a simple shim, handing out the COM interface to the VBEditor and we can slowly transfer the responibility down to only the managed COM objects.

the biggest downside is that RD would require both C# and tB knowledge if we use tB as the host. Still out on the merits.

yep.

if you look, I also defined the same COM interfaces twice, in tB and again in .NET. They aren't sharing the same definition, proving that tB can use "private" COM interfaces as long it has the correct definitions.

and tB gets that COM object out, all without any COM registrations at all.

anyway back in that project, there's no COM exposure because I don't have to go through that COM activation since I've already bootstrapped the .NET Core so I got a delegate that returns a COM interface.

@MathieuGuindon partially, yes. The recent versions bought back some aspects of it. LOL

@mansellan yes, it's now contained to each assembly.

but if you look at the .NET core hosting project above, that assembly I used does not have a .comhost.dll at all; it's not even exposing for COM.

no more regasm.exe; you just use regsvr32.exe just like you used to do

instead of having a mscoree.dll that does the work of setup and returning a COM representation, they now generate a .comhost.dll which has all the code generated to handle all that. In effect, it's now just a normal DLL

Now, with .NET Core, they changed the fundamentals of how this worked.

and if something goes wrong in one plugin, it's in the same "space" as the other plugin and it's buh-bye, baby.

so if you have 2 plugins and both are written in .NET FX, the consequence is that you are technically loading both using same mscoree.dll twice

so no matter what process you're using, you are always going through the mscoree.dll to do the initial setup and it handles the location of the .NET FX assembly, loading it and returning the COM representation from that.

which is true for ALL .NET FX assemblies

in .NET FX they made a design decision that to activate an COM-visible .NET object, they would route that through the mscoree.dll

and that DLL has to be able to self-describe everything about itself and the COM object.

In order to load a COM object you gonna to know where the DLL is, right?

Ok. Let's start all over.