Hard wired path EPPlus.dll


These are not really technical issues just suggestions.
  1. I am using Win 8.1 64-bit. If I use the msi installer the modules are all installed to the SysWOW64 folder, even though the file dialog provides the system32 folder. Not a real problem, just an inconvenience as it took a few minutes to work out what was going on when nothing showed up with the get-module. I just copied the files to the "user\documents\windows powershell\modules\excelpslib" folder.
  2. The path to the dll is hard wired to the install folder in ExcelPSLib.psm1. A better approach is to use relative paths. I simply edited the following line in ExcelPSLib.psd1.
              # Assemblies that must be loaded prior to importing this module
                RequiredAssemblies = @('EPPlus.dll')
and deletedt the following lines in ExcelPSLib.psm1.
    $DLLPath = "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ExcelPSLib\EPPlus.dll"
    # Init
    # Load The .Net Library EPPLUS
    [Reflection.Assembly]::LoadFile($DLLPath) | Out-Null
After doing the above the demo.ps1 worked like a charm.

file attachments


Avalon77 wrote Oct 2, 2014 at 5:06 PM

Thanks for your comment !

I know about the installer... I use "InnoSetup" to build my installer but I noticed that with x64 OS there is something wrong with what is displayed and the reality... Do you have any other software like InnoSetup in mind because this behaviour is definitively a bug that I can't fix...

You are right about the path, I'll update my code for the next version !

Have a nice day (or a good night) !

pianoboy wrote Oct 2, 2014 at 10:11 PM

Thanks for your reply Avalon77.
I’m a bit old school when it comes to simple powershell file deployments and just use .inf.cmd files.
I have provided an install setup for for ExelPSLib in the attached zip.
Because this is installing to system folders and registry entries you will need to run the install/uninstall cmd files as administrator. The install creates an entry in the “programs and features” appwiz.cpl listing so you can also uninstall from there. To change the install the only file you need to edit is the ExcelPSLib_Setup.inf file – mostly in the last section the strings section. If you wish to change install folders you need to change the DestinationDirs section DIRID for destination folders. The DIRID identifies the known windows folders.

The inf file can be modified to provide shortcuts on either the desktop or menus if required but that is an exercise for another day.

From the demo the psscript certainly seems be useful for creating xlsx files from scratch but at this stage I haven’t had a chance to look at it closely. I’m mainly looking for ideas on updating data to specific data cells using either powershell or xslt.

Avalon77 wrote Dec 11, 2014 at 11:23 AM


I've just released version 0.5.7 and I changed my code like told me.
I've also fixed (I hope) the problem with the install path on x64 systems... The problem wasn't Inno Setup but the Windows redirection feature on x64 systems... So, now for x64 systems the installer will install the module to "C:\Windows\sysnative\WindowsPowerShell\v1.0\Modules\ExcelPSLib".

Source : http://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm (The Sysnative folder in 64-bit Windows explained)

Zander1372 wrote Jun 2, 2015 at 9:53 PM

I've found on the recent installs I've done on 64 bit machines that it does end up in:

But it won't work correctly until you copy it over to


The only thing in WOW64 folder is unins000.dat and .exe. Once you copy the dll, ps1, psd1 and psm1 files over everything works fine.

Think the best model would to install to both folders.

pianoboy wrote Jun 3, 2015 at 12:18 PM

I can run the Demo.ps1 from the System32 folder from a 64-bit machine using 64-bit Powershell. To run it from the SysWOW64 folder I need to use the x86(32-bit) version of Powershell. If you are able to run the demo from from the SysWOW64 folder then it is more than likely you are using the x86 version of Powershell (This should be indicated by the x86 in the console window). Logically the 64bit version of Powershell should not be looking around in the SysWOW64 Modules or it will end up trying to load 32 and 64 bit versions of modules.

I'm not an expert on windows architecture but here is my 2 cents. If there are any experts out there please let me know where I am wrong as we can all benefit.

On 32 bit machines this System32/SysWOW64 dichotomy does not exist so the System32 folder is the only alternative. As long as EPPlus.dll is compiled for 32-bit or Any CPU (It is in fact compiled for Any CPU) this will work for 32-bit machines. To install to two folders adds a wrinkle to the installer as it would now need to check if 64-bit before installing to SysWOW64.

On 64-bit machines running 64-bit Powershell everything should also run well using System32 folder. Just as long as you are using .Net dll's (As proved by my ability to run the demo). However when it comes to computers nothing is ever straight forward. Here is the wrinkle and probably why we are faced with 2 versions of Powershell. Native code (.Com) is generally not so easy to accommodate, 32-bit and a 64-bit version do not play nicely with each other. Sometimes with .Com objects they only ever exist in 32-bit versions, to incorporate these in your Powershell scripts you must run the 32-bit version.

Now, if you want users who are using the x86 version of Powershell to load your module you may do as suggested place a copy in both folders. An alternative though is to just install it to "user\documents\windowspowershell\modules" then the code will be loaded regardless of which version of Powershell is used. Also depending on your install method and user permissions it may allow installation without requiring Administrator privileges. The only draw back is if you have more than one user of a machine, multiple copies would be required. For two users this would incur no greater penalty than installing to two system folders.

A 64-bit machine running a 64-bit

Avalon77 wrote Sep 7, 2015 at 11:26 AM

This issue should be now fixed...
For x64 (By default) the lib will be installed in:

and in

For x86 (By Default) the lib will be installed in: