Rename this project and nuget package

[dsyme]

Hi @lasandell.

I'm doing an audit of F# nuget packages searching for "FSharp" and this one came up as one that uses a two-word package name.

Ideally we should rename this project (and more importantly the corresponding nuget package) to follow the recently published guidelines.

Please consider renaming the library and nuget package to

• FSharp.Interop.ComProvider

or another appropriate name.

Thanks! Don

[lasandell]

Thanks, I was already planning on renaming it based on those guidelines. I was originally thinking something like FSharp.Windows.ComProvider due to guideline 4, but I sort of do like FSharp.Interop.ComProvider. Which do you think would be more appropriate?

[dsyme]

I think FSharp.Interop.ComProvider. i think there are some implementations of COM on Mono, though not sure.

• I think you should also take it out of preview once you change the name - you need to get early adopters trying it out, and the "preview" tag can retard that - it looks like the provider is in fairly good shape?
• Could you open a GitHub issue for each of the known issues listed in the README.md?
• Any chance the 32-bit limitation could be lifted? And does that mean the provider can only be used from a 32-bit program?

[lasandell]

I arbitrarily imposed the 32-bit limitation pending more research. The problem was that in addition to supplying separate runtime DLLs for each architecture, a COM component can optionally supply separate type libraries (metadata), meaning I wouldn't know which one to use to generate the interop types unless I knew the project's target architecture. I don't know of any way to detect this from within a type provider, and it still wouldn't help in the case of Any CPU.

Having just done some light research into the subject, it appears that the common case is for COM components to supply the same type library for both architectures (same IDL, GUIDs, etc.). If this is true, then it shouldn't matter which type library I use to generate the interop types in most cases, I can pick one arbitrarily. So to answer your question, it should be possible in most cases to use the current version of the provider from a 64-bit application, provided that a 64-bit version of the COM component exists. I will test this out. I will also look at modifying the provider so that it returns 64-bit-only components, which it currently filters.

This was the main reason for this remaining a prerelease - I wanted to fix these things before making the official 1.0 release to avoid semantic version inflation, but I never got back to it. I also wasn't 100% sure how I wanted to name things (TypeLib vs. COM as the root provided type, etc.). I'll try to resolve these issues in the next few days so that I can create a stable release / package with the new name.

[dzmitry-lahoda]

May you update readme with info about 32 64 from you answer not to mislead users who visit main page of project?

Most or even all COM libraries I used where same API for 32 and 64. I think if ever such happen (and most probably this will be bad COM API practice) this will be convenient to provide explicit configuration option what Windows Registry branch to check for library description.

Regarding "Type libraries with Primary Interop Assemblies (PIAs) such as Microsoft Office are not supported.".

MS Office native like MSO.dll or Excel.exe are usual COM libraries. As I know, PIA are just generated Interop of these and registered into the GAC. What is reason for mentioned limitation?

As I know TLB may be referenced by name and by GUID. Is type providing by GUID is working now? Or should be raised as issue?

I know that specific COM object may be referenced by ProgId or by GUID, and registry contains linkage of COM object to its typelib. So is it possible to implement typeproviding for single type via its reference?

[lasandell]

May you update readme with info about 32 64 from you answer not to mislead users who visit main page of project?

The underlying issue has already been resolved in master - it uses whichever type library is available. I haven't updated the documentation because I was going to do that whenever I create the stable 1.0 release package.

MS Office native like MSO.dll or Excel.exe are usual COM libraries. As I know, PIA are just generated Interop of these and registered into the GAC. What is reason for mentioned limitation?

I guess I thought there would be some issue with embedding the entire PIA in the output assembly, or that it wasn't a good practice, but after some quick research it seems like the only drawbacks would be loss of type equivalence (usually not important) and size (the Excel PIA is only a little over 1MB). In any case, I don't want to stop developers from using the type provider how they want, so I will remove this restriction.

As I know TLB may be referenced by name and by GUID. Is type providing by GUID is working now? Or should be raised as issue?

I considered the functionality but didn't think of it as high priority since it seems more convenient to use the name in most cases. I could look into adding that.

I know that specific COM object may be referenced by ProgId or by GUID, and registry contains linkage of COM object to its typelib. So is it possible to implement typeproviding for single type via its reference?

Possible, and I considered allowing querying types by their ProgIds at the beginning, but there are two issues that arise.

First, not all ClassId / ProgId entries in the registry link back to their type library - it is optional. I'm not sure of the proportion of ones that do, but some important ones like Word.Application do not. So I decided to leave that functionality out entirely rather than giving two separate ways of querying for the same type, one which would be deficient.

Second and more to the point of your question - it is not currently possible using TypeLibConverter to import just a single type - it always imports the entire type library into an assembly, which is then fed to the F# compiler via the type provider. It might be possible in some future release to detect what types are actually being used by watching for calls to ITypeProvider.GetInvokerExpression during compilation and reduce the provided assembly accordingly (which is a whole other chore because the types are already built, so it would have to rebuild them at that point), but I'm not even sure that would work. The other problem is that the single type could reference other types, so then you have to start removing members off the type and handle the vtable gaps correctly the way the "Embed Interop Types" option of the Roslyn compilers does. Definitely not a trivial undertaking. :-)

[dsyme]

Hi @lasandell

Can we go ahead and rename this repo to FSharp.Interop.ComProvider to match the code?

thanks don

[aptmcl]

Hi,

Do you have plans regarding the stable 1.0 release package?

[lasandell]

Not at the moment. I ran into some issues regarding references between COM libraries and naming clashes, especially with the MS Office components. I never actually got back to looking at it. I may create another pre-release in the meantime that includes all the fixes I made since the first pre-release. It works pretty good for most things.

[aptmcl]

Hi,

On May 23, 2016 7:36 PM, "Luke Sandell" [email protected] wrote:

Not at the moment. I ran into some issues regarding references between COM libraries and naming clashes, especially with the MS Office components. I never actually got back to looking at it. I may create another pre-release in the meantime that includes all the fixes I made since the first pre-release.

That would be great. I was trying to use the current pre-release but it doesn't seem to work in a 64 bit environment.

Kind regards, António Leitão.