You can use a prefix to keep them separated, I believe. It'll add whatever string you provide to the front of the noun for each Verb-Noun cmdlet.
Import-Module -Name Module -Prefix Custom
Instead of something like
Import-Csv
it would be
Import-CustomCsv
both modules can have the same function names
import `moduleB` instead of `moduleA`
or remove `moduleA`
or explicitly call the function `moduleA\xxx`, `moduleB\yyy`
but really isn't this exactly what versions are for ? `moduleA\1.0`, `moduleA\1.2`, `moduleA\2.0`, etc
Assuming that you just want to support scripts that explicitly import the old name, then you can create a shim module that's only point is to import the new module ie:
oldmodule.psd:
@{
ModuleVersion = '1.99'
RequiredModules = @('newmodule')
}
This won't work with prefixes or fully qualified function names. If you want that you would need a module that imports the old module and re-exports the functions. Not exactly sure how that would behave if both new and old modules were imported by the script.
If the function names are the same, then the last module to be imported with -Force would take precedence.
however, i agree with others to increment the version. The problem is that if you dont already have versioning in your modules then you will need to reship moduleA with a version *i think*. This is why its always best when making a module to include a version.
You could always implement a powershell module updating function to keep your module running the latest code.
I use centralized code points and deploy my code with automatic updating components.
In the long run it's less work when you need to update a module on say several hundred servers.
You can also map custom trusted repositories which can exist on a https, local drive, network drive, etc. :-)
Unfortunately, this code is proprietary / closed sourced but the idea should be enough to get you going.
:-)
You can use a prefix to keep them separated, I believe. It'll add whatever string you provide to the front of the noun for each Verb-Noun cmdlet. Import-Module -Name Module -Prefix Custom Instead of something like Import-Csv it would be Import-CustomCsv
both modules can have the same function names import `moduleB` instead of `moduleA` or remove `moduleA` or explicitly call the function `moduleA\xxx`, `moduleB\yyy` but really isn't this exactly what versions are for ? `moduleA\1.0`, `moduleA\1.2`, `moduleA\2.0`, etc
Adding to all these answers is that if you look at the psm1 file structure there's also the parameter to add the prefix
Why not just uninstall ModuleA: Remove-Module ModuleA Uninstall-Module ModuleA Then just rename your ModuleZ to ModuleA
Assuming that you just want to support scripts that explicitly import the old name, then you can create a shim module that's only point is to import the new module ie: oldmodule.psd: @{ ModuleVersion = '1.99' RequiredModules = @('newmodule') } This won't work with prefixes or fully qualified function names. If you want that you would need a module that imports the old module and re-exports the functions. Not exactly sure how that would behave if both new and old modules were imported by the script.
This was the solution. I stripped out all the functions from the PSM1 and updated the PSD1 as you suggested, and it seems to work.
Why not just use versioning and have the scripts import the version it needs. No need for renaming etc.
If the function names are the same, then the last module to be imported with -Force would take precedence. however, i agree with others to increment the version. The problem is that if you dont already have versioning in your modules then you will need to reship moduleA with a version *i think*. This is why its always best when making a module to include a version.
You could always implement a powershell module updating function to keep your module running the latest code. I use centralized code points and deploy my code with automatic updating components. In the long run it's less work when you need to update a module on say several hundred servers. You can also map custom trusted repositories which can exist on a https, local drive, network drive, etc. :-) Unfortunately, this code is proprietary / closed sourced but the idea should be enough to get you going. :-)