.NET Core / Standard Support

[Bluecakes]

Hi @ryannewington

Microsoft have ported the ability to consume WCF services with their dotnet/wcf library and a couple of days ago, CoreWCF v1 was released to support everything else, have you had any thoughts or plans about updating the library to .NET Core or even .NET Standard?

[ryannewington]

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.

[leoerlandsson]

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

[ryannewington]

@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.

[leoerlandsson]

@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.

[ryannewington]

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.

[andrecarrblad]

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!

[leoerlandsson]

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

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

[ryannewington]

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

[leoerlandsson]

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

[ryannewington]

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?

[leoerlandsson]

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.

[AnderssonPeter]

@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.

[leoerlandsson]

Can I help here somehow @ryannewington ? :)

[ryannewington]

Hi @leoerlandsson, I think its just the wiki doco thats outstanding to help people understand how to use it and the various modes - assuming you havent found any issues during testing?

[ryannewington]

oh gross, and the build pipeline :(

[ryannewington]

These are the outstanding tasks for the v2 release. If anyone wants to tackle one or more then that would be appreciated.

• [x] Create deployment pipeline
• [x] Publish beta packages
• [ ] Test client on Windows/net FX using built-in proxy
• [ ] Test client on Windows/net8 using net.tcp
• [ ] Test client on Windows/net8 using server-side proxy
• [ ] Test client on macOS/net8 using net.tcp
• [ ] Test client on macOS/net8 using server-side proxy
• [ ] Test client on linux/net8 using net.tcp
• [ ] Test client on linux/net8 using server-side proxy
• [ ] Write wiki installation and configuration guide for server-side proxy
• [ ] Write wiki guide for adding net.tcp bindings to FIM service .config file
• [ ] Write wiki guide for explaining different client modes/connection options

[ryannewington]

Have published the pre-release nuget packages and proxy installer https://github.com/lithnet/resourcemanagement-client/releases/tag/v2.0.11-beta

[leoerlandsson]

Hi @leoerlandsson, I think its just the wiki doco thats outstanding to help people understand how to use it and the various modes - assuming you havent found any issues during testing?

Hi,

Thanks Ryan! :)

We have found no issues so far. Had a "locked file" for the Proxy EXE one time when it was being unpacked, but haven't been able to reproduce that (probably had something to do with IIS Pool Recycling). It seems solid.

We'll try the beta nuget, and also try to help with the remaining tasks. We have some project members on holiday for 1-2 weeks, but after that we'll try performing some of the tasks above. I've created internal Tasks for this in our internal project DevOps.

Br, Leo

[leoerlandsson]

@ryannewington Do you have any general requirements for the Test clients? Are you thinking Unit Tests, or an actual GUI / Console App Test client? Thanks.

[ryannewington]

Hi Leo. I thinks its just some shake out/validation testing on linux and mac to make sure things work as expected. I have a bunch of unit tests that I can hook up to the pipeline at some point, and run them across operating systems, but it's a fair bit of work to set up in the lithnet lab.