I would like to share my M2MQTT code between a Windows 10 universal windows platform application and a windows phone 8.1 application. Perhaps a WPF app in the future.
I've attempted to use NuGet to include M2MQTT in a portable class library (PCL). I targeted the PCL with a minimum of requirements to satisfy both project types. I receive the following error. Is it possible to reference m2mqtt in a portable class library that can be shared by both UWP and WP8.1 projects?
Attempting to gather dependencies information for package 'M2Mqtt.4.2.0.1' with respect to project 'Pcl45', targeting '.NETPortable,Version=v4.6,Profile=Profile32'
Attempting to resolve dependencies for package 'M2Mqtt.4.2.0.1' with DependencyBehavior 'Lowest'
Resolving actions to install package 'M2Mqtt.4.2.0.1'
Resolved actions to install package 'M2Mqtt.4.2.0.1'
Install failed. Rolling back...
Package 'M2Mqtt 4.2.0.1' does not exist in project 'Pcl45'
Could not install package 'M2Mqtt 4.2.0.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.6,Profile=Profile32', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Additional Information 9/24/2015
I cloned the M2MQTT GitHub repository and noticed that there is a .pcl for Windows 8.1 and Windows phone 8.1. I didn't see support for UWP in a .pcl though.
I suppose I have my answer. No M2MQTT does not support .pcl in UWP projects.
Wondering if there are any plans to add .pcl support in the future?
Also if I might be able to use M2MQTT in Xamarin Android or Ios projects?
Additional Information 9/28/2015
Following suggestions from #Anders Gustafsson I successfully created a .pcl that I was able to consume in my UWP app and windows phone 8.1 app. No more duplication of code. Nice. Hope this will work in xamarin android and ios.
There is this warning.
Severity Code Description Project File Line Source Warning
Some NuGet packages were installed using a target framework different from
the current target framework and may need to be reinstalled. Visit
http://docs.nuget.org/docs/workflows/reinstalling-packages for more
information. Packages affected: M2Mqtt Pcl45 0 Build
M2MQTT is available as a PCL profile 32 assembly, which is capable of targeting Windows 8.1, Windows Phone 8.1 and Windows 10/UWP projects. The M2Mqtt.WinRT assembly is really a PCL Profile 32 assembly.
The problem you are facing is that this fact is not reflected in the NuGet package. In the NuGet package there are separate lib folders for win81 and wpa81 with the M2Mqtt.WinRT assembly in both. The desirable scenario would have been that there should have been a single sub-folder portable-win81+wpa81 containing the M2Mqtt.WinRT, then everything would (probably) have worked flawlessly for you.
There seems to be one workaround, although I cannot promise that it is fully reliable.
Start off creating a portable class library, but set the only target for the PCL to Windows 8.1. (If that does not work immediately, create a PCL that targets Windows 8.1 and Windows Phone 8.1, and when the PCL has been created, uncheck the Windows Phone 8.1 check box.)
Add the M2MQTT package from NuGet to your PCL. Your PCL will now reference the M2Mqtt.WinRT assembly in the win81 sub-folder.
Add Windows Phone 8.1 as a target of your PCL, so that your PCL (again) targets both Windows 8.1 and Windows Phone 8.1. You may receive warning messages from NuGet when doing this; ignore those messages.
Now, you should be able to consume the M2Mqtt.WinRT assembly from your PCL, and you should also be able to reference your PCL in a UWP application.
To add more reliability once you have managed to download the M2MQTT package from NuGet, you might manually delete and then re-add the reference to the M2Mqtt.WinRT assembly in your PCL project. That way you will short-circuit NuGet, preventing NuGet from accidentally trying to restore your M2Mqtt.WinRT reference from a non-existing (portable-win81+wpa81) directory.
I cloned the M2MQTT GitHub repository and noticed that there is a .pcl for Windows 8.1 and Windows phone 8.1. I didn't see support for UWP in a .pcl though.
I suppose I have my answer. No. M2MQTT does not currently support .pcl in UWP projects.
Related
Guys I have a solution containing projects of Api, class libraries and a WPF app.
All of targets are .Net Core 3.1.
I used Wix tools to create a self-contained installer.
It works well on windows 10 (well, it should) but i need an installation on windows 7.
But after installation the app doesn't start and there is no errors.
1- Is there any specific configuration for old windows 7?
2- if yes Which configurations should i check for existing projects?
Is there any specific configuration for old windows 7?
Yes, there is, according to https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1-supported-os.md#windows, you must have SP1 installed, and according to https://learn.microsoft.com/en-us/dotnet/core/install/windows?tabs=netcore31, you need additional dependencies (KB2533623 update).
Obs. I had a similar problem in my test environment, and installing SP1 + KB2533623 solved the problem.
Regards.
For me, installing sdk on windows 7 solved the issue https://dotnet.microsoft.com/download/dotnet-core/3.1
I'm trying to move to MSIX to install our application, which is currently deployed to our customers via a ClickOnce installation which requires updating on startup, if there is an update. Its a .Net Framework (4.7.2) WinForms app. I'm a bit lost on how to begin; the documentation seems to start from an existing installer package (including ClickOnce), but I'd like to generate this without an intermediate step on our build server as we want to phase out the ClickOnce installation completely once we've proven MSIX will work for us.
I found the Windows Application Packaging Project, but it seems targeted to UWP app, which ours is not, and we have the need to install on Windows 7 SP1 or higher.
What tool would I use to create an MSIX package non-interactively? Would the WAPP play any role in the process?
Here is a similar thread on MSFT's MSIX community. It's talking about VS 2017, but most of the info applies to 2019 too.
https://techcommunity.microsoft.com/t5/msix-packaging-and-tools/build-msix-from-vs-2017-pro-v-15-9-4/m-p/952246
An extract from the above link:
You should be able to use the windows application packaging project to package MSIX. Please see: https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-packaging-dot-net
Alternatively, you could package your MSIX by hand using: https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-manual-conversion
Additionally, if you want to use the MSIX Packaging Tool, you might be able to leverage our pre-made VM: https://learn.microsoft.com/en-us/windows/msix/packaging-tool/quick-create-vm even if your enterprise is still on an older release of windows.
You can also try partner solutions, like Advanced Installer's VS extension which can build an MSIX and MSI from the same project, if you need to target different users. The extension also supports debugging apps inside the msix container.
Disclaimer: I work on the team building Advanced Installer.
We already have a working UWP app for x86, x64 and ARM. Everything is fine regarding store certification, all tests are passed, including with .NET native compilation.
We would like to use the Desktop Bridge (similar to what is specified here: https://blogs.msdn.microsoft.com/appconsult/2016/12/19/desktop-bridge-the-migrate-phase-invoking-a-win32-process-from-a-uwp-app/) to add a small .NET 4.6.1 WPF side-kick app to the main UWP (x86, x64) versions. The WPF app has three dependencies(x86 and x64) on some native dll's which are packaged together with the rest of the app.
We added the WPF.exe app and dll's to the existing UWP package (like specified in the above blog post - using xcopy) and built packages for HockeyApp. Locally and functionally, everything works fine for both x86 and x64. Once uploaded to the ms dev center, the Store certification unfortunately fails with the following error:
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain"
-- but native compilation is already enabled for UWP Release x86, x64.
We then tried to create a Windows Application Packaging Project (like described here: https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net#generate-packages-for-your-desktop-bridge-app) and add both the UWP app and the WPF as dependencies. Then we created a new app manifest and store association (unfortunately it does not seem possible to reuse the existing manifest from the UWP app). We built the app store packages for (x86 x64 Release) and successfully tested everything locally. We then uploaded the package to win dev center and got again the same errors as before
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain".
As a follow up we removed the UWP project from the Windows Application Packaging Project and set the WPF app as an entry point. We then built a store package, uploaded it and the .NET native compilation error disappeared. Which is very weird...
Somehow the combination of UWP and WPF (even with native compilation enabled for UWP) causes this certification error. We have a feeling that something is wrong with the packaging.
We would really want to get this combination working or we will have to fall back to having two separate apps: one pure UWP and one packaged WPF companion app which needs to be installed separately. We truly wish we wouldn't have to do this. I'm not sure what we are doing wrong and for the moment I have run out of ideas.
PS: We also know we need to fill and submit a form regarding the restricted capability: full trust. But before we do that we need to be sure that everything else is fine.
UPDATE 4/21/2018
The workaround explained below is no longer needed, and in fact will not be accepted by the Store anymore. The right way to properly package a UWP app with a Win32 extension is to use the new VS Packaging Project, and then create the store package off of that project in VS. Details are in this blog post, see example #3 for this specific case:
https://blogs.windows.com/buildingapps/2017/12/04/extend-desktop-application-windows-10-features-using-new-visual-studio-application-packaging-project/#uvfV1r7937WrSkX2.97
OUTDATED ANSWER BELOW
You are hitting a known flaw in the Store ingestion process for packages that contain a mix of UWP and Desktop .NET binaries. The Store team is actively working on resolving this, so it will work automatically for submissions of this type. In the meantime you can do the following to get unblocked:
Manually create your.appxupload as follows (see screenshots for clarity below):
Go to the output folder for the AppPackage
Select the .appxsym files and the .appxbundle file
Create a new .zip file from those
Rename the .zip file to .appxupload
Resubmit to the Store with the new .appxupload file
MSDN does not list a WPF .exe as a supported type of application for ClickOnce
A ClickOnce application is any Windows Presentation Foundation
(.xbap), Windows Forms (.exe), console application (.exe), or Office
solution (.dll) published using ClickOnce technology.
http://msdn.microsoft.com/en-us/library/t71a733d.aspx
I do find evidence around the web that non-XBAP WPF apps work with ClickOnce, but are they officially supported?
Yes, ClickOnce does support WPF applications compiled to executables. ClickOnce is nothing more than an installation distribution method. The primary difference between creating an installation package and ClickOnce (other than being web-based) is that ClickOnce applications are installed within obfuscated folders within the end user's Windows directory.
The means that ClickOnce applications can be installed with a non-administrator account. The caveat to this method is that an application can not be installed on a PC and shared across other user accounts on the PC-- each user must re-install the application.
WPF requires the .NET 3.0+ framework. When you publish your ClickOnce application, you will need to include the .NET 3.0 (or 4.0) framework. Once you add the prerequisite to your project, ClickOnce will check the user's PC to see if the framework is installed. If not, it will pre-install it before installing and running your application. If it already exists, it will skip the download and installation of the framework.
If you need to install a third-party library or application, custom pre-requisites can be created and added to your projects. It is worth noting, prerequisites may need to be installed by an administrator, depending on the rights of the end user. This may seem a bit counter-intuitive, but it's just the nature of the installation process.
ClickOnce is a very simple, but robust installation mechanism, and I've used it extensively. It's not appropriate for every circumstance, but it can certainly accomplish what you are asking.
For ClickOnce, there is no difference between a Windows Forms executable and a WPF executable. Both are .NET executables and as such fully supported by ClickOnce...
I have personally deployed several WPF desktop applications using ClickOnce, and it worked exactly the same as with my Windows Forms applications...
I'm Trying to deploy my winforms project using installshield in order to make is available to be installed on other computers. My project is written under .net framework 3.5.
My question is : What version of .net package should be installed on the target machine in order to be able to run my project?
One thing to notice is that target machine is not connected to internet so I have to embed a standalone offline installer for .net framework.
Surely, with .Net framework 3.5 full redistributable package installed, my project runs fine. But it's ~200MB. Should I really install 200MB in order to run my ~10MB project on target machine?
one other option would be installing client redistributable package which I heard ~30MB. But I couldn't find any official release and am not sure if that's gonna work.
Any help would be appreciated.
You should deploy with the web installer so that it can determine what your client needs and download only those components. The full install is that big because it contains all variants of the framework for all possible systems (x86, x64, etc.).
This site from Scott Hanselman is an excellent resource on the matter of deploying .NET.
http://www.hanselman.com/smallestdotnet/
As it states on that site:
If you look for .NET Downloads on
Microsoft's site, it might look like
the .NET Framework is 200+ megs. It's
not. Those big downloads are the
Complete Offline Versions of every
version of the .NET Framework for
every kind of machine possible. The
big .NET download includes x86, x64,
and ia64. It includes .NET 2.0, 3.0,
and 3.5 code for all systems all in
one super-archive.