Doesn't Work Deployed as ClickOnce

[SimonEvans482]

Sample WPF Application using DYMO Connect SDK works fine in Visual Studio but has issues when published using ClickOnce.

once published DymoPrinter.Instance.GetPrinters() does not return any printers, despite them being available on the client machine and accessible from Dymo Connect / Dymo Label.

Deployed Sample app also crashes on label load, claiming element DieCutLabel does not exist in template (it does), though works fine in IDE.

[becker-ncg]

I have the same problem with a Windows Forms application. I'm using the new DYMO SDK Dymo.Connect.SDK provided by NuGet in a Windows Forms app (.Net Framework 4.8). I want to list all available dymo printers. When debugging the app or starting the exe, everything works fine and the printer is found. When I deploy the app as ClickOnce, no printer is found.

[dymosoftware]

Hi @SimonEvans482 and @becker-ncg , check out your deployed folder contains the DYMO DLLs and SkiaSharp.

• DYMO.LabelAPI
• DYMO.LabelAPI.PlatformSpecific
• DYMO.CrossPlatform.Common
• DYMO.CrossPlatform.Common.PlatformSpecific
• DYMOPrinting and x64
• PrintingSupportLibrary and x64
• DYMO.Common
• libdymobarcode
• SkiaSharp, SkiaSharp.Views, libSkiaSharp in x86/x64 folders

[becker-ncg]

The following dlls were not deployed into the click once application files folder: DYMOPrinting, PrintingSupportLibrary, libdymobarcode and libSkiaSharp. I could add DYMOPrinting, PrintingSupportLibrary manually from packages\DYMO.Connect.SDK.1.3.2.137\Build. libdymobarcode.dll couldn't be added from there and libSkiaSharp.dll also fails.
With dlls DYMOPrinting and PrintingSupportLibrary deployed, the ClickOnce app is now able to display the available printers. However printing still fails, because libSkiaSharp is missing.
Why arent't all these dlls automatically added to the Application Files dialog box like all the other dlls mentioned above that are included in the SDK?

[becker-ncg]

I tried to update SkiaSharp with NuGet, but the newest version is not compatible with DYMO.
Dependencies could not be resolved.. "SkiaSharp 2.80.2' is not kompatible with 'DYMO.Connect.SDK 1.3.2.137 restriction: SkiaSharp (= 1.68.0)' . (original: Abhängigkeiten können nicht aufgelöst werden. "SkiaSharp 2.80.2' ist nicht mit 'DYMO.Connect.SDK 1.3.2.137 Einschränkung: SkiaSharp (= 1.68.0)' kompatibel.)

[lapoPaolacci]

I've the same problem, anyone have some good news?

[skillsinc-Ed]

I was able to work around it by looking at the build in the \bin\debug that was working and see what files were missing from my ClickOnce deployment.
I added these to my project and set them to Build Action: Content and Copy if newer:

libSkiaSharp.dll
x86\DYMOPrinting.dll
x86\PrintingSupportLibrary.dll
x86\libdymobarcode.dll
x86\LW5xxCommunicationLibrary.dll
x86\usps4cb.dll

I messed around with mag.exe and building a custom manifest and it just was nothing but a hassle. At least this method will still allow me to make updates to my code and quickly publish.
Nice advantage to upgrading my apps from the old SDK to the new Dymo Connect SDK is that I'm no longer tied to the version of the Dymo software installed on the endpoint.

This is all after I had already added as much to my references as I could, the problem is that the SDK files in the x86 folder MUST be in the x86 folder and you must set the Compile target to x86. I didn't need the x64 folder.

These are the dll files I had in my build (that were not already in the x86 folder)
I had to manually add libSkiaSharp.dll, but the rest were added as References.

DYMO.Common.dll
DYMO.CrossPlatform.Common.dll
DYMO.CrossPlatform.Common.PlatformSpecific.dll
DYMO.LabelAPI.dll
DYMO.LabelAPI.PlatformSpecific.dll
DymoSDK.dll
libSkiaSharp.dll
netstandard.dll
SkiaSharp.dll
SkiaSharp.Views.Desktop.dll
SkiaSharp.Views.Gtk.dll
SkiaSharp.Views.WPF.dll

I will post my sample vb.net source code here for anyone who needs it:
https://github.com/skills-inc/Dymo-Connect-SDK-Sample-Application-for-VB.net

[Tronald]

I was able to mix @skillsinc-Ed and @dymosoftware solutions to come up with a working solution for myself that gets the project working and deploying correctly using ClickOnce targeting .NET Framework in Visual Studio.

I had to perform these steps in this exact order.

In Nuget Command Line

Install-Package SkiaSharp -version 1.68.0.0
Install-Package SkiaSharp.Views -version 1.68.0.0
Install-Package Dymo.Connect.SDK

Once packages have been installed, navigate in Windows Explorer to [Your Project Directory]/packages and copy the following files to your project. Be sure to set the Copy to Output Directory Property to "Copy if newer" for each file.

DYMO.Connect.SDK.[Version]/build/DYMOLib/[ALL FILES] to Project
DYMO.Connect.SDK.[Version]/build/DYMOLib/Win/[ALL FILES] to Project
DYMO.Connect.SDK.[Version]/build/DYMOLib/x86/[ALL FILES] to Project/x86 (Create new folder if needed)
DYMO.Connect.SDK.[Version]/build/DYMOLib/x64/[ALL FILES] to Project/x64 (Create new folder if needed)
SkiaSharp.1.68.0/lib/net45/SkiaSharp.dll to Project
SkiaSharp.1.68.0/runtimes/win-x86/native/libSkiaSharp.dll to Project/x86
SkiaSharp.1.68.0/runtimes/win-x64/native/libSkiaSharp.dll to Project/x64

Should look like this when complete.

[ksladowski]

I did that and when I try to run the deployed app I get "Application cannot be started. Contact the application vendor.

Any ideas? Been stuck on this for weeks

[Tronald]

@ksladowski can you post the log file that's generated from the "Application cannot be started..." message? It should tell you why it failed then we can look into it further.

[1zerro1]

With the latest Nuget package DYMO.Connect.SDK version 1.4.3.37, the only thing missing is the reference to SkiaSharp.Views
Easy Fix : Install Nuget package that fit with the version of SkiaSharp referenced by DYMO.Connect.SDK. In my case was version 1.68.0.

For the developer who managed the nuget package :

• Include that dependency so nobody faces the same issue again.
• Change the doc for the dependencies. SkiaShape >= to 1.68.0 seems to be false. It should be SkiaShape = to 1.68.0 ­.
  Peace out.

[jangusff]

Just noting that the advice provided above by 1zerro1 on Aug 24, 2022 helped resolve the issue I was having here in August of 2023.

[booktrakker]

The DLLs are unsigned, and this becomes a major hassle. Please sign DLLs with an SNK.

[booktrakker]

I tried signing the DLLs using a method I have used in the past and I get an error, so I cannot sign the files. This eliminates my ability to support Dymo printers, so I will have to tell my users to buy Zebra printers, which just work without any of the major hassles I have spent the last two months dealing with.