I have a PowerShell module that I have created and is installed in the WindowsPowerShell\Modules path. I can auto-discover the module if it installed in the root of the module folder, example WindowsPowerShell\Modules\NewModule, however if I create a sub-folder in the module folder, the module is not long auto-discovered, example WindowsPowerShell\Modules\NewModule\1.0.
Why would the module stop being auto-discovered by adding the module and manifest to a sub-folder in the Module folder? I have plenty of modules using this structure that auto-discover fine. Thank you!
Regarding why the others are working, I'm guessing it's how PS installed the module depending on where it's sourced from (i.e. modules installed from PSGallery typically are in a version subfolder). Per the MS docs on installing modules though, the parent module folder should be directly in your module path in order for it to be recognized correctly as a module:
https://msdn.microsoft.com/en-us/library/dd878350(v=vs.85).aspx
That being said, if you're creating modules and storing them all in a subfolder in your PSModulePath, you should be fine just updating your PSModulePath environment variable to include that subfolder as well. Once done, reload your PS session and retry your import.
Related
When I use
perlbrew lib create testlibs
to have a folder to store test libraries from CPAN, it creates a folder under the following path:
$HOME/.perlbrew/libs/perl-5.32.0#testlibs/lib/perl5
How can I tell perlbrew to store the libs folder ( perl-5.32.0#testlibs ) under a different folder such as /opt/perl5/libs, etc.?
I have very little disk space for home mountpoint on my server, so I need libs folders to be created on a different mountpoint. I already have PERLBREW_ROOT set to a different mountpoint, but that only makes perlbrew install new perl installation folders under it. It doesn't do it for the libs folders, which was surprising.
I already read the documentation and googled the hell out of this, but I can't find some env variable I can use to tell perlbrew where to install libs folders.
I know I can manipulate locallib env variables and even use lib on my scripts to point to some other folder, but it would be nice to have this all included within perlbrew.
I am trying to compile several scripts in my project into an easier to move and manage DLL file, however several scripts call UnityEngine.UI, and I know that the DLL file used to exist in /Contents/UnityExtensions/Unity/GUISystem/Editor/UnityEditor.UI.dll however the only data I can find for it now are the uncompiled files inside the Package Manager, where is the compiled DLL stored now?
The simplest answer that I just found is to look in the project folder of one of your projects in Library\ScriptAssemblies
My book tell to add PHPUnit path to Global Include Path in Netbeans, but its use out of date PEAR way.
I installed PHPUnit using composer global require "phpunit/phpunit xxx". I run this command right in c:\
I got main PHPunit directory in: C:\Users\xxx\AppData\Roaming\Composer\vendor\phpunit
and two files in:
C:\Users\xxx\AppData\Roaming\Composer\vendor\bin
It depends, on how much code-completion support you want.
If you want the code-completion to work for all globally installed Composer packages,
then the path would be
C:\Users\xxx\AppData\Roaming\Composer\vendor
When you set this "Include Path" Netbeans will automatically scan the whole vendor folder and provide completion support for all classes of all packages. Scanning might take a while...
If you want completion support only for PHPUnit, then adding
C:\Users\xxx\AppData\Roaming\Composer\vendor\phpunit
is sufficent. Only the content of the phpunit folder will be scanned.
(I use the first approach, because PHPUnit has several other dependencies/packages (e.g. phpunit-selenium) and its nice to have support for these classes, too.)
The bin folder should contain a batch file: phpunit.bat.
This script might be used in the testing/ phpunit configuration as the "PHPUnit Script". When you invoke testing, this script will be used to start the Composer installed PHPUnit (, instead of the PEAR one).
I am creating a NuGet package, which is a library DLL. I did this successfully.
However I would like to have a .NET exe (and its dependent assemblies) also in the target machine. It is completely OK if the .exe and these dlls are under the solution's package folder.
If it is possible I do not want to create a standard Windows installer and run it silently.
Thanks in advance
You'll have to edit your .nuspec file. You can include a element to include additional files in your package. Look at what else you can do by looking at the specs.
You can run your exe by creating a powershell script during package installation.
Starting from NuGet 2.0 a package can contain a "tools" folder. Here you can put exe, scripts and so on.
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Framework_Version_Folder_Structure
Binary under this folder will not be referenced, just copied on the machine.
Hope it helps.
I am creating NuGet Package. I have put two files in content folder, exe and config files that will be added when user installs this package.
In addition I would like to change VS project properties for these two files.
What do I need to do for that when building the package?
When you say "apply properties change" do you mean file system properties such last modified time, hidden flag, etc.?
If so there are a set of PowerShell scripts that are run (if they exist in your package) you can use to do this. It won't happen when you build the package, but it will run when somebody installs the package - which should have the same effect form the users point of view. You probably want either Init.ps1 or Install.ps1.
From Automatically Running PowerShell Scripts During Package Installation and Removal in the NuGet docs:
A package can include PowerShell scripts that automatically run when
the package is installed or removed. NuGet automatically runs scripts
based on their file names using the following conventions:
Init.ps1 runs the first time a package is installed in a solution.
If the same package is installed into additional
projects in the solution, the script is not run during those
installations.
The script also runs every time the solution is
opened. For example, if you install a package, close Visual Studio,
and then start Visual Studio and open the solution, the Init.ps1
script runs again.
Install.ps1 runs when a package is installed in a project.
If the same package is installed in multiple projects in a solution,
the script runs each time the package is installed.
The package must have files in the content or lib folder for Install.ps1 to run. Just having something in the tools folder will not kick this off.
If your package also has an init.ps1, install.ps1 runs after init.ps1.
Uninstall.ps1 runs every time a package is uninstalled.
These files should be located in the tools directory of your package.
At the top of your file, add this line: param($installPath, $toolsPath, $package, $project)
$installPath is the path to the
folder where the package is installed
$toolsPath is the path to
the tools directory in the folder where the package is installed
$package is a reference to the package object.
$project is a
reference to the EnvDTE project object and represents the project the
package is installed into. Note: This will be null in Init.ps1. In
that case doesn't have a reference to a particular project because it
runs at the solution level. The properties of this object are defined
in the MSDN documentation.
When you are testing $project in the console while creating your scripts, you can set it to $project = Get-Project