Giters

jdhitsolutions / PSScriptTools

:wrench: :hammer: A set of PowerShell functions you might use to enhance your own functions and scripts or to facilitate working in the console. Most should work in both Windows PowerShell and PowerShell 7, even cross-platform. Any operating system limitations should be handled on a per command basis. The Samples folder contains demonstration script files

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug]: Conflict with NTFSSecurity module causes PSScriptTools to fail to import

kborowinski opened this issue · comments

commented

Describe the problem

PSScriptTools fails to import with exception Error in TypeData "System.IO.FileInfo": The member Size is already present. when imported after NTSSSecuirty module:
image

This is also true when the import order is reversed, with the exception that then NTFSSecuirty module fails to import

Reason

Both modules define custom alias property Size for the System.IO.FileInfo type

Expectation

PSScriptTools should import successfully regardless of the import order.

Additional Information

There is similar issue opened in the NTFSSecurity repo, however since nothing was done about it for more than a year, I was hoping that @jdhitsolutions will try to fix it on his end (if possible).

PowerShell version

7.4

Platform

Windows 11 Pro or Enterprise

Additional Checks

  • You are using the latest version of this module.
  • You have read this repository's README file.
  • You have read full help and examples for the command you are having problems with.
  • You are running PowerShell in an elevated session.
  • You are running in a traditional PowerShell console or Windows Terminal
commented

This really isn't a bug as much as by design for PowerShell. If two modules both add a type extension, it is up to the user to decide which module they want to use. In this situation, you can't import both modules in the same session. If you get the error, you must run Remove-Module on what is already loaded and then import the other module. Both modules are importing a types.ps1xml file, and there's no place in the module to force an overwrite, which would have unintended consequences even if you could. There's also no mechanism to import the module without the conflicting type extension. That, too, might have unintended consequences.

The bottom line is that this is not a problem a module author can fix, which is probably why you saw no action on the other module.

If you truly need to run both modules in the same session, I suggest forking the modules and creating customized versions that eliminate the conflicts.

commented

Closing since this is not something I can control.