Tool: Visual Studio, Visual Studio Code, PSScriptPad, PowerShell Module
Version: 5.30.1
When compiling my EXE I am seeing a warning that says:
warning NETSDK1107: Microsoft.NET.Sdk.WindowsDesktop is required to build Windows desktop applications.
I have tried to find a download for this but was unable. There are some links that didn’t work located here: NuGet Gallery | Microsoft.NET.Sdk.WindowsDesktop 3.0.0
Can anyone tell me how to suppress this or what to look for in my code?
This should be included with the .NET Core SDK. Can you let me know what version you have installed?
You can run this on the command line.
dotnet --version
3.1.411
Adam do you have any suggestions to get rid of this error? My .Net version is 3.1.411. This is preventing me from deploying the latest version of the tool.
Hey @markdmac,
I can reproduce this. It looks like a problem with the csproj that’s being generated. That said, it doesn’t fail the build for me and is just reported as a warning.
Is you build failing to produce an executable?
It does generate an EXE. But since getting this .Net error I am seeing very strange behavior.
If I execute the EXE from within PSScriptPad, everything works fine. There is no background PowerShell window opened, just the form and all functions work.
When I close that and directly runt he EXE, a PowerShell window opens when the script loads modules. That then shows errors loading the MSOnline module.
The module loads fine via PSScritpPad and in a PowerShell window directly. The errors I am getting are:
Import-Module : Could not load file or assembly ‘file:///C:\Program
Files\WindowsPowerShell\Modules\MSOnline\1.1.183.57\Microsoft.Online.Administration.Automation.PSModule.dll’ or one of
its dependencies. An attempt was made to load a program with an incorrect format.
At line:38 char:2
Import-Module MSOnline
~~~~~~~~~~~~~~~~~~~~~~
[Import-Module], BadImageFormatExceptionConnect-MsolService : The ‘Connect-MsolService’ command was found in the module ‘MSOnline’, but the module could not
be loaded. For more information, run ‘Import-Module MSOnline’.
At line:39 char:2
Connect-MsolService -Credential $Cred365
~~~~~~~~~~~~~~~~~~~
Get-MsolUser : The ‘Get-MsolUser’ command was found in the module ‘MSOnline’, but the module could not be loaded. For
more information, run ‘Import-Module MSOnline’.
At line:40 char:13
$MFAUser = Get-MsolUser -UserPrincipalName $ADUser.UserPrincipalN ...
~~~~~~~~~~~~
I don’t understand why it would work properly in PSScriptPad but not when executed directly in the EXE.
Typically, a bad format exception like this has to do with invalid process architecture. In the package.psd1 file, you can set the platform to adjust that.
If you aren’t using a package.psd1 file, here’s some info on how to do that: PSScriptPad - PowerShell Pro Tools
Are you running the x64 or x86 version of PSScriptPad?
Interesting playing with that Package.psd1 file. I was able to hide that console window, and was able to force x64, but the PoshKeePass module doesn’t work when I did that and I need that for pulling our service account credentials.
If I remove the Platform = ‘x64’ the script runs but the modules still don’t load and I cannot grab needed account information from the MS cloud.
If I run this same code from within PSScriptPad it works. So what translating is that doing to make the modules load properly when they won’t in the EXE?
I just noted the question about version of PSScriptPad. Not sure how to tell. I click to launch it from VSCode. Top right shows 5.11.18362.1714 | 5.13.3. I don’t know how to tell if it is x86 or x64 though.
The x64 version is bundled with VS Code.
I’m not exactly sure why these modules are misbehaving in the packaged executable. When packaging Windows PowerShell scripts, the packager uses the same entry point and assemblies as the PowerShell console. That said, we do some additional configuration before starting scripts.
I might need to try these modules myself to see if I can determine why they aren’t packaging correctly. I’ve opened an issue to track this work.
Thanks Adam. Hopefully something comes up to fix this. It is odd that this just started happening. Past builds did not give these errors.
For the time being, you can always roll back to a previous version: Installation and Licensing - PowerShell Pro Tools
Is there a list of versions I can reference? I noted my Pro Tools updated today, so I would need to go back 2 versions I think.
Here you go: PowerShell Pro Tools for Visual Studio Code - PowerShell Pro Tools
I think this is the build that introduced the warning you are seeing: PowerShell Pro Tools for Visual Studio Code - PowerShell Pro Tools
Adam, I downloaded the latest PSScriptPad in both x86 and x64. If I package my script outside of VSCode using the x86 version, everything works perfectly, however the package.psd1 is ignored and I don’t get the custom icon. Not the end of the world but it would be nice to have. Is there a way with just PSScriptPad to have it use the package.psd1 information?
I rolled back my PowerShellPro tools as far back as version 5.29.3. I noted I still got the warning message and the resulting EXE can’t load the modules. Something in the Pro Tools extension isn’t handling the x86 stuff right. (at least that is my assumption)
I did download the latest versions of x86 and x64 PSScriptPad. I copied the x86 version to the folder C:\Users\MyUserID\.vscode\extensions\ironmansoftware.powershellprotools-5.30.1\out\windows and repackaged the script. It used the PSD1 to set the icon, it did not load the modules. So it does seem to be specific to VSCode being used to package, I assume that means the issue is with PowerShell Pro Tools.