// Grasshopper Script Instance
#region Usings
using System;
#r "nuget: System.DirectoryServices.AccountManagement"
using System.DirectoryServices.AccountManagement;
using System.Linq;
using System.Collections;
using System.Collections.Generic;
using System.Drawing;
using Rhino;
using Rhino.Geometry;
using Grasshopper;
using Grasshopper.Kernel;
using Grasshopper.Kernel.Data;
using Grasshopper.Kernel.Types;
#endregion
public class Script_Instance : GH_ScriptInstance
{
#region Notes
/*
Members:
RhinoDoc RhinoDocument
GH_Document GrasshopperDocument
IGH_Component Component
int Iteration
Methods (Virtual & overridable):
Print(string text)
Print(string format, params object[] args)
Reflect(object obj)
Reflect(object obj, string method_name)
*/
#endregion
private void RunScript(object x, object y, ref object a)
{
// Write your logic here
a = UserPrincipal.Current.DisplayName;
}
}
PlatformNotSupportedException: System.DirectoryServices.AccountManagement is not supported on this platform.
at Script_Instance.RunScript(Object x, Object y, Object& a) in rhinocode:///grasshopper/1/a88ced93-8613-4ac1-8fa9-0e7402fa9148/b24263ae-8212-4bb5-ae55-aded8664a1b0:line 44
Not a bug. NET Core is supposed to be smaller and cross-platform. Basically any niche or non-cross-platform part of the standard library has been removed. You now need to add respective NUGET packages if you want to use it. For some Windows-only code you are required to compile with “Net7.0-Windows” flag inside. Could be that the script component does not allow it. You can however write a custom .dll and load it in via script. I would do it anyways if you do something fancy like this.
I guess you did not understand. You are calling Windows-specific code on a script which gets compiled as a cross-platform dll (in memory). It makes perfect sense to get this exception. Even on Windows. You need to workaround it. Simple answer, you can’t use AD/LDAP features in GH C# scripts like this anymore.
Could you provide more info about your idea of workaround? Connection to AD is out of question and only way to get “offline” user related information is via UserPrinciple which is part of System.DirectoryServices.AccountManagement library. Or is it :)?
This is uncharted terrain. Some of my NET core apps are accessing the LDAP, but I explicitly compile as Windows only. As I said, you could try to bypass this limitation by writing a dedicated dll. But I‘m not sure if this solves it. But wait, if you want only information about the current offline user, you likely get it from somewhere else! What kind of information are you asking for?
I tried compiling something similar on a net7.0-windows target framework but still getting the issues.
When I in VS inspect the dlls, they reveal that every single property will throw the exception.
Still struggling to find real windows usernames, as our windows logins are XX1231 and the displaynames are “Mathias Schaltz”. I would like to log our display names and not the login names, but I guess those days are gone now with .NET7.
@DavidRutten Any change to get some support from Grasshopper/Rhino developers? Used assemblies are .net7 (System.DirectoryServices.AccountManagement - version 8 + dependencies), component is compilied againts target net7.0-windows… Everything should work, but it is still crashing…
I created this thread, looks like it’s not supported in UWP. However I did not on intention create an UWP project. Didnt do thorough research but perhaps its implicit with .net7-windows
Another workaround would be to create dedicated console application and either run it from Grasshopper and read the standard output. Just as you do a lot in Linux.
e.g.:
Or you even use IPC and communicate with this dedicated app using named pipes, local tcp etc. Although I think this is a bit of an overkill.
