Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
5 tasks done
kborowinski opened this issue Feb 3, 2024 · 2 comments
Closed
5 tasks done
Assignees
Labels

Comments

@kborowinski
Copy link

kborowinski commented Feb 3, 2024

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
@kborowinski kborowinski added bug triage new issue that needs review labels Feb 3, 2024
@jdhitsolutions
Copy link
Owner

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.

@jdhitsolutions jdhitsolutions added pending feedback and removed triage new issue that needs review labels Feb 3, 2024
@jdhitsolutions
Copy link
Owner

Closing since this is not something I can control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants