Imported Module not working in *.exe file

[GHIsolierung]

Version PS Studion 2017 v 5.4.141 on Windows 10 x64 latest

Hello
I have similar problems as in this topic
viewtopic.php?f=21&t=8876&start=10

The module Bits-Transfer starts without problem when I start my application from Powershell Studio, even if I export it to a * .ps1 file.

If I create an * .exe file from it, the module is not loaded.

* Loading the module in the 'global section' did not work

Error message from the console is:
'Import module could not load file or assembly. Microsoft.BackgroundintelligentTransfer ......, dll or one of its dependencies. A dynamic link library initialization routine failed .... '

The settings are: V5 - 64bit
Compiled (or how to call it in PS Studio), converting to an exe file has the setting:
'Script Engine: V3 host (Windows Forms), no config.file'

*.exe file tested on Windows 10, Server 2012R2

Best regards

[Alexander Riedel]

Please do not post technical questions in the "Customer Service" section. Always post in the relevant forum section and provide the details requested. Please note that "latest" for Windows is not a valid version number as it can change between posting and reading this and it might be different for different geographic locations.

As the other solutions for this problem point out, the issue stems from mixing runtime versions. Microsoft does not always update binary modules to the latest runtime version.
This is where you need to use the config file the build process normally generates for you. By what you posted, you turned that off. Is there any specific reason for doing so?
Try turning this back on and see if that solves your problem.

[GHIsolierung]

This has solved the problem.
The reason was that I did not want another file to be generated. I just want to have a single * .exe file.

Is it not possible to embed into the * .exe file?

[Alexander Riedel]

As far as I know, .config files which contain startup information to support different .NET runtime versions must be outside.
Microsoft arranged for it this way. Any particular reason why this is a problem? Most .NET applications have these files.

[GHIsolierung]

Honestly, it just bothers me.
I am writing only mini-applications, for example an extended Active Directory search or a Hyper-V configuration program. I just want to have an exe in a corresponding directory.
It's more of an optical thing.

Can I influence this within my code, that this file is not necessary? So far, I have never created this file. Only in this application where I had to load a commandlet do these problems occur

Many thanks for your help

[Alexander Riedel]

So OCD ? Jokes aside, the .config files are necessary if you mix assemblies compiled against different runtimes. You can go to the vendor of the module or assembly and ask them to update their stuff, but then you will have to distribute those along with your app.
Put all you executables in a single \bin folder and have single shortcuts to them in your folder structure.
Then you only have a single file and you don't see the "mess"

But in all honesty, as your apps get more complex your will get multiple files. config files. settings files. additional sub tools. etc.
So get used to it

[GHIsolierung]

ok and alright then.

Thank you for your help and for explaining it to me.