Unfortunately, they have not added support for message security that fim service requires.

I've ported the whole code base over to dotnet core, but without message security support, it can't talk to the fim service and is pretty useless.

The have said that they don't plan on adding this support. The only option that leaves is petitioning the mim team to add a dotnet wcf compatible binding to a future version of the mim service.

@ryannewington Any update here? I saw a tweet where you were running .NET Core on Linux? Can I help with anything?

@leoerlandsson yes I did get it mostly working. I was waiting for .NET 8 to come out to add some required linux support. I just haven't had a chance to get to it.

It's all in this branch

https://github.com/lithnet/resourcemanagement-client/blob/dotnet-standard2.0

There's a few modes of it working, one is by adding a new net.tcp endpoint to the FIM Service, which .NET core can connect to natively. The only limitation is this can't be done for the approval endpoint. So only resource create/add/modify works.

An example config is here

https://github.com/lithnet/resourcemanagement-client/blob/dotnet-standard2.0/src/Lithnet.ResourceManagement.Client/sample.nettcp.config

The other is by installing a proxy service on the FIM service box, that relays loopback calls back to the wshttp endpoint. This also offers full support for all clients.

On windows, this proxy is actually embedded in the RMC library. When you try to connect it will extract an .NET FX EXE, launch it, open a named pipe session to it, and proxy all calls from .NET core to the .NET FX library so there is full support.

The client will try to figure out what mechanism to use, but you can force it by just modifying the url passed to the client
http://fimsvc <- use WsHttp native client, as normal. works only on .NETFX
net.tcp://fimsvc <- use NetTcp (forgoing support for approvals) - requires the modification to the FIM service .config file to add the additional server-side binding. Works on all platforms
rmc://fimsvc <- use the RMC proxy installed on the FIM server - has full support for all platforms
pipe://fimsvc <- use the inbuild .NET FX EXE file to proxy calls from .NET core to .NET FX - has full support for all features but is windows only.

if you just provide fimsvc it will perform the following steps

1. If loaded inside a .NET FX process, use the WsHttp binding as per normal
2. If running on windows, use the embedded FX EXE
3. Otherwise try use the RMC proxy on the server

The linux problem was that the before .NET 8, the .NET negotiate support incorrectly prevented allowing 'impersonation' - hard coded on the client side, so it prevented the remote proxy from being able to impersonate the user to the WsHttp endpoint. NetTcp was working fine, but as mentioned, didnt have support for the approval endpoints.

From memory, next steps were just to finalize the linux support, get doco done and make the packages. All the unit tests were updated and working. It's very close to being done.

@ryannewington Thanks Ryan. Amazing work as always.

I'll talk to my colleagues and see if we can help finishing it. Please don't hesitate to reach out if there's anything we can do.

Testing would be great! - I think its code complete, and just needs doco to be update. but I'll circle back to it this weekend and see if there is anything still to do.

I have tested the client.GetResources(filter, attributesToFetch) method on .NET 8 using the pipe://fimsvc endpoint, and the results match those obtained from my .NET 4.8 Framework application. Great work!

@ryannewington Any new developments here? Can we do anything to help?

We'll be launching extensive tests here in the coming months.

Hi @leoerlandsson

No development at this stage. I've been a bit busy in ECMA2 land of late.

Have you uncovered any issues in your testing to date? Happy to try get it packaged and released in time for when you need it if you have specific deadlines.

Ryan

Hi @ryannewington

I know about ECMA2 land. It can be mesmerizing.

No issues at all uncoved. I did some performance tests, and was surprised pipe was faster than net.tcp.

No specific deadlines, but "Spring 2024". We can use the branch in the meantime.

We'll get back to you with more test results as they progress.

Thanks again Ryan.

Br,
Leo

That's really interesting. I wonder why that is?

Am working on a new ecma framework and it's so cool 😎. Full async support, multithreaded exports, dependency injection, Ioptions configuration support. Paging results back to fim is all handled. Iextensiblema2 code is all auto generated with source gen.

But yeah if you find any issues with this happy to accept PR or send me the details and I'll get it fixed up.

Are you going to be calling from Linux or just windows?

Yeah, I was surprised about the performance. I would absolutely expect net.tcp without the proxy to be faster.

The new ECMA2 framework sounds awesome. Looking forward to that.

At this time we will be calling from Windows, so all four connectivity options will be available for us.

@ryannewington Thanks for a great package!
Do you have any idea when you will be able to create a nuget package?
We currently use git submodule, but it's far from an ideal solution.