1

Having an issue getting a dependency to deploy w/ a VB.NET WinForms app. The app runs, but errors when the DLL is referenced/used.. The DLL is not inside the user's install directory upon inspection.

I installed a new NuGet package (first NuGet in this solution) and it works great. I've implemented it, tested locally. Looking at the bin folder (this is in debug), I see the DLLs are all there.. great.

I can publish the application w/ ClickOnce with "No Issues". I am deploying to IIS 8.0 w/ a Web Share. The DLL isn't there though on the web server, either.

The "Application Files..." menu under "Publish" has all CefSharp references as "include", "required", "include" across all cols. This forces ClickOnce to include them as resources right?

Under references in Visual Studio, they're all set to Copy Local = True. However... when I change Copy Local nothing changes in my GIT history/change history!! Visual Studio sees and recognizes the .vbproj was modified, however there weren't any visible (unicode?) changes. I can commit.

I am on the latest version of Visual Studio, VS2019 16.8.2 for Blazor/ASP.NET Core reasons. Should I try downgrading?

I added a Chromium wrapper based control to replace the generic IE7 Web Control in .NET Framework. I'm working in an .NET 4.6 app. x86.

CefSharp GIT Repo. https://github.com/cefsharp/cefsharp

I'm using the CefSharp.Common and CefSharp.WinForms namespaces in my application.

Warnings saying unable to publish properties for the DLLS.

Edit: Possible Duplicate: Unable to apply publish properties for item X

Edit2:

Here is an excerpt from my .vbproj

  <ItemGroup>
    <PublishFile Include="CefSharp">
      <Visible>False</Visible>
      <Group>
      </Group>
      <TargetPath>
      </TargetPath>
      <PublishState>Include</PublishState>
      <IncludeHash>True</IncludeHash>
      <FileType>Assembly</FileType>
    </PublishFile>
    <PublishFile Include="CefSharp.Core">
      <Visible>False</Visible>
      <Group>
      </Group>
      <TargetPath>
      </TargetPath>
      <PublishState>Include</PublishState>
      <IncludeHash>True</IncludeHash>
      <FileType>Assembly</FileType>
    </PublishFile>
    <PublishFile Include="CefSharp.WinForms">
      <Visible>False</Visible>
      <Group>
      </Group>
      <TargetPath>
      </TargetPath>
      <PublishState>Include</PublishState>
      <IncludeHash>True</IncludeHash>
      <FileType>Assembly</FileType>
    </PublishFile>
    <PublishFile Include="FlexCell">
      <Visible>False</Visible>
      <Group>
      </Group>
      <TargetPath>
      </TargetPath>
      <PublishState>Include</PublishState>
      <IncludeHash>True</IncludeHash>
      <FileType>Assembly</FileType>
    </PublishFile>
  </ItemGroup>
  <ItemGroup>
    <WCFMetadata Include="Service References\" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="CefSharp.Common">
      <Version>86.0.241</Version>
    </PackageReference>
    <PackageReference Include="CefSharp.WinForms">
      <Version>86.0.241</Version>
    </PackageReference>
  </ItemGroup>

SOLVED BY: Edit: This didn't fully solve my issue alone but was a hack attempt to bring in all resources, manually, and it worked.

Edit 3: OK None of these solutions worked including downgrading to 16.4 lol that was fun. Please install your required CefLibrary.WinForms etc libraries.. Then build the project.. it needs to actually build. This generates .dlls in your \bin directory in your file system.

Edit 4: Gave up. Visual Studio 16.8.2 and 16.8.1 are both just outright broken. You can do down the rabbit hole (this is December 2020) but it looks like the visual studio team https://github.com/dotnet/roslyn/issues/48679 is having issues with references right now. (that one feature that's been the same for 20 years) They don't even have an eta - after they broke a crucial feature - in a enterprise/production product. This wasn't a preview lol. How did this pass unit testing :D For my use case of CefSharp I needed to load a PDF. I am not directly using an Adobe ActiveX control instead.

Take a look at this request https://github.com/cefsharp/CefSharp/issues/3274 This was very very recent (nov 2020) and he "fixed" it Move these out to a better place, maybe a "references" folder then actually reference them manually through VS2019 like you would any other .dll.

I'm assuming this is a bug and not the intended workflow since it wasted almost 10 hours of rabbit hole googling nearly. <-- This was in fact a bug.

Solution: There is none. Evidently. On the latest version of everything as of Dec 2nd 2020 - stable and all - your own CefSharp implementation will be broken even when properly setting up to spec of other examples if compiling w/ 16.8.1 or 16.8.2 (but it doesn't seen to be working with 16.6.2 either)

https://github.com/cefsharp/CefSharp/issues/3274

  • See https://stackoverflow.com/questions/34225222/clickonceinstall-cefsharp-winforms-problems and https://github.com/cefsharp/CefSharp/issues/1314 – amaitland Dec 01 '20 at 19:16
  • 1
    I personally avoid Clockonce as it's difficult to debug. If you bin deploy to the target machine does it work as expected? Basically confirming all dependencies are installed. Using https://github.com/cefsharp/CefSharp/issues/1314#issuecomment-653698789 should include all the required files when using packages.config. You are using PackageReference so it may be a little different, make sure to include the targets after the PackageReference entries. Your publishfile entries only include the managed resources, the unmanaged won't be copied. – amaitland Dec 03 '20 at 01:19
  • I've also learned to despise-slightly-then-more-and-more as the random, unsuspected and often confusing errors occur. What's that, your app is erroring for the user now but only some users? I've seen MS responses with "Just tell the user to uninstall first" what a joke. I use ClickOnce in my job for deploying many WinForms apps. Edit: Please check all my responses and above edits. It's not my fault the config is wrong. MS Responded above and said internally fixed. Too bad that was a month ago though. (16.9 preview announced then same time) – anon-fishy-boi938 Dec 03 '20 at 19:48
  • 1
    I'd suggest using https://msbuildlog.com to analyse the build output, very useful for debugging click once. – amaitland Dec 03 '20 at 21:24

0 Answers0