WebView2Loader.dll is still missing from App.Publish (Winforms, ClickOnce).

[pipalot]

ClickOnce is still missing WebView2Loader.dll and the x86, x64 and arm64 directories containing the various version of WebViewLoader.dll. None of which are copied to the App.Publish sub-directories when I publish using ClickOnce.

According to 228, this was supposedly fixed in 0.9.628-prerelease. That issue report is now closed, hence why I am starting a new issue report (presumably that is what is expected?).

Versions tested:
SDK 0.9.628-prerelease
SDK 0.9.579-prerelease
both the above tested with and without the amendments to the Targets file mentioned in 431 and 228, but still the files are not copied to App.Publish when publishing with ClickOnce.

Runtime: Edge Canary and Edge WebView2 Runtime. I have tried with both/either installed.
Framework: WinForms
OS: Win10
Visual Studio 2019
Building and publishing in Release mode.
Platform Target: x86 (not been able to test x64 or Any CPU, because of other DLLs in my project that require x86)

Thanks for any help, I'm out of ideas.

AB#29816653

[champnic]

A new issue is great, thanks for the report! If you do open a new issue, no need to comment on the original issue.

Can you try uninstalling and re-installing the nuget package (rather than updating)? Sometimes I find if a file has been touched then it won't overwrite it during update.

Can you try fully cleaning and then rebuilding the solution, and then try publishing?

If those don't work let me know and we can dig in more.

[pipalot]

Hi @champnic and thanks for your reply. Still no luck unfortunately after following those instructions.
I uninstalled the nuget package and even deleted it from the %userprofile%\ .nuget\packages location too so that no trace of the package existed.
Then I cleaned the solution.
Then I reinstalled WebView2 0.9.628-prerelease.
Then rebuilt the solution and finally published the project.
Everything else in my project published as expected, but there is still no copy of the x86, x64 or arm64 directories (or any separate copy of WebViewLoader.dll) being put into the project's bin\release\App.Publish directory or its sub-folders, or in the publish location.
I forgot to mention, I'm using .NET 4.6.2 as the target framework.

[pipalot]

The three directories (x86, x64 and arm64) containing the versions of WebViewLoader.dll, do appear in the bin\release folder after building the project, but they just don't get copied to bin\release\App.Publish (or any of its subdirectories) when I publish with ClickOnce.

[pipalot]

I have narrowed it down and can now give precise steps to reproduce it. The problem happens when the WebView2 control is in a project that is not the main published project, but is referenced by and called by another project that gets published. For example if Project1 contains the form with the WebView2 control on it, and Project2 references Project1 and calls the form in Project1. Then when you publish Project2, the x86/x64/arm64 directories containing WebView2Loader.dll versions will not be published.

Steps to reproduce:

1. Make a new solution with the project name as Project1
2. Add the Nuget package WebView2 0.9.628 to the project Project1
3. Drop a WebView2 control onto Form1 in Project1.
4. Now make another new project in the same solution, lets call it Project2
5. Insert the following code into Form1 of Project2, so that when it runs it opens Form1 of Project1:

namespace Proejct2
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            Project1.Form1 form1 = new Project1.Form1();
            form1.Show();
            this.Visible = false;
        }
    }
}

6. Build Project2 in release mode.
7. Publish Project2, for example to a temp directory on your local hard disk just for simplicity.

Inspect the contents of the publish location and see that the x86, x64 and arm64 directories are missing. They are also missing from Project2\bin\release\App.Publish

So if the project containing the WebView2 control (Project1) is reference by another project (Project2) then the files are not copied when publishing Project2 with ClickOnce.

If Project1 is just published directly on its own, without Project2, then the files are copied correctly when publishing with ClickOnce.

I don't understand Target files, but I began to wonder if this problem be caused by something in the Targets file? Perhaps it tries to copy the files to a location relative to the wrong project?

[champnic]

Thanks for continuing to investigate this - this is a really interesting scenario! I'm not super familiar with having projects with references to other projects, and how the targets file interacts with that. One thing I'd note is that the "Publish" command is on the project, not the solution, and so I wonder if publishing a project with references to other projects is not fully supported?

For example, these threads suggest potential workarounds and sound like they're having similar issues (though the threads are quite old):
https://stackoverflow.com/questions/819823/clickonce-references
https://social.msdn.microsoft.com/forums/windows/en-US/3641b884-a826-4d47-9a97-052ae3a5e1ae/clickonce-deploy-files-from-other-project-in-a-solution

[pipalot]

Hi @champnic and thanks for your reply and those links, but I don't think they are helping because a folder can't be added as an 'existing item' to a project.

I imagine it is a fairly common requirement to have a project referenced by another project, for example if project1 is a library (or on my case project1 is executable project that can also be referenced as though it was a library for project2).

I have also tried adding the WebView2 package to Project2, which I'm making some progress with as this forces the missing directories to be published when Project2 is published. However, it won't run yet, even when using the improved Targets file proposed in 431.

I am continuing to experiment at length to try to force it to work but thus far I'm having no success. I feel that the true solution should be that the Targets file should be made to copy the required directories, so that WebView2 controls can be included in projects that are referenced by a published project. Unfortunately I have no idea how to amend a Targets file and can't fathom that out, so I hope someone might be able to answer that.

[champnic]

Ya I would imagine this is a pretty common scenario too, so it's surprising it doesn't #JustWork. That's a good idea to include WebView2 in the Project2 as a workaround (without having to move all code from Project1 to Project2).

Note: if you are running on Canary builds you might be hitting #535. New issue that showed up recently. If that's the case, you can change to use Dev or Beta builds.

[pipalot]

Thanks for your quick reply. I think I've just managed to get my workaround running for the time being, with the WebView2 package installed into both projects as mentioned above, to ensure that the required directories are included by ClickOnce. I also had to use the improved Targets file proposed in #431 to ensure that the program runs.

It isn't an particularly elegant workaround, but at least I've got something working.

Thanks for noting Issue 535. Actually, I'm not running on Canary anymore, just WebView2 Runtime.

[champnic]

Glad to hear it's working! Fixes for #431 and #535 should be coming shortly, so fewer workarounds will be necessary. I'll open a bug to track seeing if we can improve the publishing experience when project is referenced, but given the workaround is easy it's unlikely we'll get to it soon. Thanks!

[pipalot]

Thanks, opening a bug would be great and I'm glad to hear that those other fixes are coming shortly.
Actually, the above workaround is not proving easy after all, the slightest change seems to throw it into turmoil and it stops working again, even with the workaround.
I have another solution in which the directories aren't even being created in bin\debug when the project is rebuilt and the nuget package 0.9.628-prerelease is taking 13 minutes to reinstall (even though it is already on my hard drive) after changing the targets file in the pacakage (as per #431).

So I'd be really really grateful if this would not be regarded as too low on the priority list please, because trying to work around the shortcomings of the nuget package and the publishing experience is actually proving really difficult.
Many thanks!

[champnic]

I wouldn't suggest doing the target file changes for #431. The easier solutions are building specifically x64 for now, or toggling the state of "Prefer32Bit" in Project > Properties > Build settings if using AnyCPU.

It sounds like there are potentially larger issues if a nuget is taking 13 minutes to reinstall without changing the disk, or regular build scenarios are busted. My recommendation is to start fresh from a Nuget perspective - uninstall WebView2 Nuget and delete it from disk (if using PackageReferences instead of packages.config). Then reinstall 0.9.628-prerelease and verify the targets files no longer have your changes. You could also wait till our next release (very likely next week) which will have fixes for #431.

[pipalot]

Hi @champnic. Thanks for your message. I have tried doing all that but unfortunately the problems continued to exist.

Just to clarify, here are the full results that I have found so far:

The x86/x64/arm64 directories are now not even being copied to bin\debug when I rebuild my big complex solution. This is a separate problem that occurs when building/rebuilding (not the same as the problem when publishing). I haven't been able to reproduce this problem within new fresh solutions that I've created as a test.

Yesterday the directories had appeared OK at first in bin\debug when I built, but now they are gone and wont come back. They were there (in bin\debug and bin\release) when I identified the problem of them not being copied to app.publish during ClickOnce publishing. So this is not the cause of that publishing problem.

I think the directories might have first stopped appearing in bin\debug after I uninstalled the package from my project, cleaned the solution and manually deleted the three directories using File Explorer. I tried to replicate those steps by making a simple new solution and doing the exact same thing but could not reproduce it. In the fresh new solution, I can always delete the directories using File Explorer as many times as I like and they will always reappear next time I build the solution.

Interestingly, when I have 0.9.628-prerelease installed in my complex solution and do a rebuild of the WebView project, the file WebViewLoader.dll (x64 version) gets copied to bin\debug, almost as though the Targets file from an earlier version is being used. As I understand it, that file should not get copied to bin\debug during building with 0.9.628-prerelease, just the three directories that contain versions of it should be copied. So I'm getting the single file, instead of the three directories. I get the x64 version, even when I select x86 in project properties.

So I deleted all the nuget packages from %userprofile%.nuget\packages and solutionfolder\packages, before reinstalling 0.9.628-prerelease, but the same thing keeps happening.

All of the above tested with the original Targets file, not a changed one.

It is a pity that I haven't been able to create definitive steps to reproduce this in a new solution.

Would you like me to open a separate issue for the above problem?

I confirm that the original problem (the one in title of this discussion) still exists and can always be reproduced as mentioned, meaning that the x86/x64/arm64 directories are not copied to bin\release\app.publish when I publish a project that references another project that contains the WebView.

The 13 minute delay to reinstall 0.9.628-prerelease is not occuring at the moment. That delay seemed to be eradicated when I downgraded to 0.9.579-prerelease, uninstalled it then reinstalled back to 0.9.628-prerelease.

So in conclusion, the problem at point 1 above, is now stopping me even getting back to trying to overcome the original problem mentioned in point 2.

If I downgrade to 0.9.579-prerelease then my project builds OK and puts WebViewLoader.dll (correct platform version) into bin\debug. However, I doubt that it makes sense for me because 0.9.579 doesn't work with ClickOnce, so I'd just be looking at more workarounds there.

Sorry to write such a long message! I hope the information helps to make sense of it though.

[pipalot]

I updated Visual Studio and problem at point 1 above might have gone away, because I managed to build the project and get the directories to appear in bin\debug. Time will tell if it is now stable, or whether this was a red herring.

So hopefully just the original problem remains (the title of this discussion), i.e. the inability to publish a project that references another project that contains a WebView, because the three directories containing the platform versions of WebViewLoader.dll don't get copied to app.publish when using ClickOnce.

Thanks for your help so far and hopefully this thread is now simplified again, fingers crossed.

[champnic]

Thanks for the clarification @pipalot. I've update the bug to track the remaining issue. Thanks!

[ma-majumder]

I also faced similar issue. My WPF ClickOnce application crash at runtime. After reading some comments and doing some analysis I have found that "publish\Application Files{ApplicationName}_1_0_0_0" doesn't contain WebView2Loader.dll and no entry in *.manifest file. I have tried several workaround but nothing work for me.

Finally I have unchecked "Produce single file" and it solved my problem.

You can change it under "File publish options" from publish dialog

Or open *.pubxml and change to
<PublishSingleFile>False</PublishSingleFile>