$conn variable in global - can we make that optional?

[evilclivegit]

The use of $global:conn raises a few eyebrows for me for a couple of reasons - first, it's a global variable, which just seems a bit odd for module, and second, it's a variable name which could easily clash with other pieces of code. Do we need the global variable, and if we do, can it be made somewhat more unique to this?

(Is this bit based on code provided by MS? )

[seanmcne]

@evilclivegit $global:conn is a legacy artifact from when the module was first put together/written. At the time, it was a simple way to keep a persistent connection available without requiring -conn $myConnection on every call, which made it easier for newcomers to explore their environments and build functions around the provided global variable. This design was similar to how some early Microsoft modules tracked connection state internally, those compiled modules used their own code to manage a persistent connection whereas we sought to implement this module in script form rather than compiled code. The goal, at the time was to offer an admin something that worked but was also approachable and something they could learn from and understand how it worked - hopefully letting an admin get complicated tasks automated and offer them the ability to self-diagnose and learn.

That approach probably isn’t necessary today. PowerShell now offers cleaner ways to manage state, and relying on a global variable can cause name collisions with other code (if that code happened to use $conn and wasn't used for a connection to a dataverse environment). You can use your own connection variables and pass them into cmdlets, or even maintain multiple connections side by side to handle parallel connections and also the module itself wouldn't use the global variable (since you'd be passing it in via the -conn parameter):

$connection1 = Connect-CrmOnline ...
$connection2 = Connect-CrmOnline ...

This approach avoids relying on the global variable and keeps your session state explicit - unfortunately, I don't think the cmdlets can determine if the user is assigning the output or not so it's not as simple as assuming it's assigned and detecting if it should fall back to a global.

It's possible it could be re-written (though it could potentially break anything existing) also, this module isn't going to work in environments like powershell 7 and is limited by Crm Service Util which has since been replaced. If someone had bandwidth to take a run at modernizing while preserving backwards compatibility w/ the new libraries, it could continue to move on but there are some pretty big hurdles to that and may not be feasible.

[seanmcne]

PS: I just noticed it looks like someone may have designed a similar module to this one using modern libraries https://github.com/rezanid/PSDataverse - not entirely sure if it follows a similar pattern or not at this point but I might have to look into it and see how closely it aligns to this (maybe it's a way for some folks looking for powershell 7 support to move forward).