3 ms·

What part of Powershell is broken? Are you referring to module compatibility or other issues? For my shop, the AD module was an obstacle until v7. Many Azure-r

by lc9er 6y ago

What part of Powershell is broken? Are you referring to module compatibility or other issues? For my shop, the AD module was an obstacle until v7. Many Azure-related modules still seem to be 5.1 only.

jiggawatts 6y ago
The module compatibility thing isn't just developers being lazy and not porting over their modules, it's actually a fundamental thing to do with the way .NET Core was architected. Because -- you know -- in the 2020s there are only web apps and mobile apps. There are no other types of "applications". That unnecessarily long word only exists in dead tree dictionaries like Oxford, and is used by old people that still cling to their "personal computers" of yesteryear. So of course, .NET Core was made only for web apps, with a hint that mobile apps might one day work also. Microsoft will say otherwise, of course, but in practice 100% of the decisions were to ship an MVP that can be used to create a web application. All the doco was for web apps. All of the samples were for web apps. Whenever there was a decision to be made, they made it with web apps in mind. This has made some things impossible, especially related to actually loading dynamic link libraries (DLLs) dynamically, which despite the "dynamic" in the name is surprisingly problematic in .NET Core. It really wants you to ship a monolithic, statically linked app. Anything else is just a nightmare of compatibility shims and flags that ought to be at the DLL level but are actually set (once only) at the EXE-level. This makes PowerShell Core modules very sensitive to the exact version of .NET Core used to compile PowerShell itself, contrary to how the old PowerShell used to work, where you could upgrade the system framework to enable the loading of a newer module built against that framework. Similarly, if there is another module that pulls in something with compatibility shims (or not), then that can break your module in weird and wonderful ways. I tried to write a .NET Core module for PowerShell core several times, and every time I got bogged down in reams of inscrutable internal framework errors that had 2-3 hits maximum in Google, all from other people complaining about PowerShell development having being broken.

by lc9er 6y ago

jiggawatts 6y ago

The module compatibility thing isn't just developers being lazy and not porting over their modules, it's actually a fundamental thing to do with the way .NET Core was architected. Because -- you know -- in the 2020s there are only web apps and mobile apps. There are no other types of "applications". That unnecessarily long word only exists in dead tree dictionaries like Oxford, and is used by old people that still cling to their "personal computers" of yesteryear. So of course, .NET Core was made only for web apps, with a hint that mobile apps might one day work also. Microsoft will say otherwise, of course, but in practice 100% of the decisions were to ship an MVP that can be used to create a web application. All the doco was for web apps. All of the samples were for web apps. Whenever there was a decision to be made, they made it with web apps in mind. This has made some things impossible, especially related to actually loading dynamic link libraries (DLLs) dynamically, which despite the "dynamic" in the name is surprisingly problematic in .NET Core. It really wants you to ship a monolithic, statically linked app. Anything else is just a nightmare of compatibility shims and flags that ought to be at the DLL level but are actually set (once only) at the EXE-level. This makes PowerShell Core modules very sensitive to the exact version of .NET Core used to compile PowerShell itself, contrary to how the old PowerShell used to work, where you could upgrade the system framework to enable the loading of a newer module built against that framework. Similarly, if there is another module that pulls in something with compatibility shims (or not), then that can break your module in weird and wonderful ways. I tried to write a .NET Core module for PowerShell core several times, and every time I got bogged down in reams of inscrutable internal framework errors that had 2-3 hits maximum in Google, all from other people complaining about PowerShell development having being broken.