Libs not included into CLickOnce publish app root folder about fluentftp

[FanDjango]

I just experimented with ClickOnce.

Try using LoadLibraryDllNamePrefix = "Libs\\Win64\\", as config for FluentFTPGnuTls. It worked for me.

[FanDjango]

See #1347

Thank you for your rant.

If you know how to achieve this, please enlighten us.

[hovek]

See #1347

Thank you for your rant.

If you know how to achieve this, please enlighten us.

Well, based on my programming experience, programmer is the one that defines where his program is look for libraries and how his program functions, right? One example is .NET MVC which goes through series of folders searching for files and you already know that your libs are in Libs folder. Maybe NuGet package can be constructed differently, how he includes FluentFTP.dll, FluentFTP.GnuTLS.dll, maybe he can include other dlls also to be copied to bin root folder on build.

[FanDjango]

Doesn't really work that way for DllImport. Very restricted search order. Read up on it.

So it boils down to placing the .dlls in the right folder, since you can't point to some folder of your own liking.

Which means you must have the right statements in place for MSBUILD csproj etc. to put them in the right place in different scenarios.

Teach me.

[FanDjango]

But I agree that this is an open problem, waiting to be fixed.

[hovek]

Maybe NuGet package can be constructed differently, how he includes FluentFTP.dll, FluentFTP.GnuTLS.dll, maybe he can include other dlls also to be copied to bin root folder on build.

Maybe NuGet package can be constructed differently, how he includes FluentFTP.dll, FluentFTP.GnuTLS.dll, maybe he can include other dlls to be copied to bin root folder on build?

[FanDjango]

Guy, too many maybe maybe for me.

[hovek]

Guy, too many maybe maybe for me.

I am not a programmer for this app nor I have time for it, I am giving quick suggestions of path I would take. You asked for it. :)

[FanDjango]

It was a big MSBUILD fight to get the foreign, non-managed dlls to be copied in in the first place, also trying to make sure that not too many multiple copies are kept in the Nuget, to keep it small.

Ok, thank you for the suggestion.

[hovek]

It was a big MSBUILD fight to get the foreign, non-managed dlls to be copied in in the first place, also trying to make sure that not too many multiple copies are kept in the Nuget, to keep it small.

Ok, thank you for the suggestion.

Another maybe:

[FanDjango]

The .dlls are already in the ClickOnce folder, but under Libs\Win64. We've done our part.

[FanDjango]

If you "publish" to a folder, nothing needs to be done as the .dlls are in the same file as the .exe
If you "publish" to click once, the .dlls go to Libs/Win64. You then need to code the config as I posted.

I think the reason for the difference is the publish to click once is trying to reconcile "portable" whereas to folder is more primitive

[hovek]

If you "publish" to a folder, nothing needs to be done as the .dlls are in the same file as the .exe If you "publish" to click once, the .dlls go to Libs/Win64. You then need to code the config as I posted.

I think the reason for the difference is the publish to click once is trying to reconcile "portable" whereas to folder is more primitive

Interesting is that ClickOnce knows to include NuGet pkg "main" dll, so my idea was to somehow include other dlls into NuGet that would behave the same and get picked up by ClickOnce, but maybe they can't. Possibly creating NuGet pkg for each extra dll and reference those packages into the main NuGet pkg.

[FanDjango]

I remember reading that VS, MSBUILD, .NET and NuGet like to differentiate beween managed dlls and unmanaged (foreign) dlls. So that is a real pain, the unmanaged typically don't get copied, deployed etc. without any special actions. And they get put in different places... you can't really rely on anything as it depends on the type of publish/deploy.

[FanDjango]

Just make sure you don't select "Produce Single File" on the publish settings - this somehow does not even copy the dlls, not even to the wrong place. They are simply missing. Still working on that to find out whats wrong.

[hovek]

While debugging it works, but when published it does not work, still can't find dlls and they are present in Libs/Win64. Again maybe because relative path gets screwed up or fluent ignores the prefix, because when I copy dlls to root of ClickOnce installed app folder, it works.

C:\Users\hrvoj\AppData\Local\Apps\2.0\GMHH1ZGH.9RW\671MP0HQ.2A5\clan...exe_0000000000000000_0001.0009_hr-hr_9a8e43760506f3df\Libs\Win64

[FanDjango]

Interesting. That picture, is exactly mine and it worked.

But I was using

                    client.Config.CustomStream = typeof(GnuTlsStream);
                    client.Config.CustomStreamConfig = new GnuConfig()
                    {
                        //SecuritySuite = GnuSuite.Normal,
                        //SecurityOptions = new List<GnuOption> {
                        //		new GnuOption(GnuOperator.Include, GnuCommand.Protocol_All),
                        //		new GnuOption(GnuOperator.Exclude, GnuCommand.Protocol_Tls10),
                        //		new GnuOption(GnuOperator.Exclude, GnuCommand.Protocol_Tls11),
                        //	},
                        //SecurityProfile = GnuProfile.None,
                        //AdvancedOptions = new List<GnuAdvanced> {
                        //		GnuAdvanced.NoExtensions,
                        //	},
                        SetALPNControlConnection = string.Empty,
                        SetALPNDataConnection = string.Empty,
                        //LoadLibraryDllNamePrefix = "D:\\temp\\",
                        LogLevel = 0,
                        LogMessages = GnuMessage.All,
                        LoadLibraryDllNamePrefix = "Libs\\Win64\\",
                    };

See the LoadLibraryDllNamePrefix? Thats why I did set it, because I also checked the click once install directory of my small test app.

[FanDjango]

But it still does not solve my real problem, publishing to a single executable still does not include the native dlls.

[hovek]

Interesting. That picture, is exactly mine and it worked.

But I was using

                    client.Config.CustomStream = typeof(GnuTlsStream);
                    client.Config.CustomStreamConfig = new GnuConfig()
                    {
                        //SecuritySuite = GnuSuite.Normal,
                        //SecurityOptions = new List<GnuOption> {
                        //		new GnuOption(GnuOperator.Include, GnuCommand.Protocol_All),
                        //		new GnuOption(GnuOperator.Exclude, GnuCommand.Protocol_Tls10),
                        //		new GnuOption(GnuOperator.Exclude, GnuCommand.Protocol_Tls11),
                        //	},
                        //SecurityProfile = GnuProfile.None,
                        //AdvancedOptions = new List<GnuAdvanced> {
                        //		GnuAdvanced.NoExtensions,
                        //	},
                        SetALPNControlConnection = string.Empty,
                        SetALPNDataConnection = string.Empty,
                        //LoadLibraryDllNamePrefix = "D:\\temp\\",
                        LogLevel = 0,
                        LogMessages = GnuMessage.All,
                        LoadLibraryDllNamePrefix = "Libs\\Win64\\",
                    };

See the LoadLibraryDllNamePrefix? Thats why I did set it, because I also checked the click once install directory of my small test app.

ClickOnce screws up, when I remove manifest file from installed folder it works, even when I return the file it still works. ClickOnce is a finicky peace of crap. Removing manifest and running the app cause something to change, then returning the manifest, it still works.

[hovek]

CoreCLR Version: 8.0.23.53103
.NET Version: 8.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: FluentFTP.GnuTLS.GnuTlsException: GnuTLS .dll load/call validation error
---> FluentFTP.GnuTLS.GnuTlsException: Could not load Libs\Win64\libhogweed-6.dll, (0)
at FluentFTP.GnuTLS.Core.GnuTls.FunctionLoader.Load(String dllPath, Boolean storePointer)
at FluentFTP.GnuTLS.Core.GnuTls.LoadAllFunctions()
at FluentFTP.GnuTLS.Core.GnuTls.GnuTlsCheckVersion(String reqVersion)
at FluentFTP.GnuTLS.GnuTlsInternalStream.Validate(Boolean log)

[FanDjango]

I believe you... I found out that ClickOnce when using SingleFile will use Libs/Win64/...dlls, even though they are in the apps.publish folder. When ClickOnce is not doing singlefile output, it works differently.

I have been playing around with the build process of FluentFTP.GnuTLS itself, but there is nothing there that is worth. changing.

I think the problem is with Click Once. I can't even cause it to copy the dlls using the <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>. It simply does nothing.

It is old, and then they dumped it. People protested and they brought it back for NET 5. But in GitHub DotNet there are many reports of strange behaviour and quick dirty fixes etc.

Probably I will not spend more time on this, it's crazy.

[hovek]

Yea, I gave up and just moved dll links to the root of the project.

[FanDjango]

@hovek It is fixed, I found a solution. Please read #1347 !