I'm working on a windows store app project where I want to read a simple temperature measurement data from a National Instruments DAQ. However the DLL library for the DAQ is in .NETFramework 4.0 format and when adding this as reference to my windows store app project I get the following error: "The project targets ‘.NetFramework’ while the file reference targets ‘.NetCore’"
Searching the net, I found out that windows store app must use references to another .NETCore or Portable Library binary only, it cannot reference a full .NET 4.0 library. I guess there is many people who have similar problems,so I wonder if there is any walk around tricks out there?
If you're stuck with using a library supplied by someone else, and if attempts to lobby them to produce a portable version are unlikely to succeed, then about the only thing you can do is find somewhere else to host the DLL, and then communicate with whatever is hosting it. For example, for some scenarios it may be possible to write, say, an ASP.NET Web API based service, which will be able to use the full .NET Framework and will thus be able to use the DLL.
Obviously, this trades one problem for another: you now need to have a machine which can run a web service for you. (And unfortunately, I believe Microsoft does not officially support running that web app on the same machine that's running the Windows Store app. You may be able to get it to work on your dev box, but you'll not be able to deploy the web app itself via the Windows Store.)
And there's no easy path here - you'll have to write a layer exposing everything you need via HTTP services, and client-side code to consume those services. And you'll also need to think about how to to secure access to the service.
It may be easier to plead with your supplier...
In theory, if it so happens that the library isn't using anything outside of the core .NET profile, then you could use ILDASM and ILASM to de-compile and re-compile the code, converting it to a portable library before doing so. However, this is quite likely to breach your license agreement if it's commercial code, and in any case, is quite likely not to work.
The "workaround" is to create a version of the library you want as a portable library. That's all there is to it. You simply don't have the full framework available.
The difficulty involved in converting a class library to a portable class library depends heavily on what the library does, and which areas of the BCL it uses.
Related
I am currently working on a WinForms app in Visual Studio 2019, which uses a USB to I2C adapter to read EEPROM register values from a device. The manufacturer of the adapter provides the driver for the device in a downloadable zip file on their website which contains the .inf and .sys files among other things. I would like to have it so when the end user installs the app, the driver is automatically installed as well. What is the best way to do this? I have a Setup project in my solution, which I can use to put the driver files in the application folder, but that doesn't mean the driver is actually set up.
I found one potential solution that used System.Configuration.Install, but my targeted framework at the moment is .NET core 3.1, which unlike .NET framework does not have that namespace. I am only expecting users to use Windows 10, so I theoretically could switch to .NET framework for that namespace if necessary. However, I don't know if that will break anything in the app or if that is the easiest way to go about this.
I am very new to deploying apps so I really don't know the best way to go about this. Any direction is appreciated.
There are third-party .net core ways of doing this, such as
Core.System.Configuration.Install
Porting of System.Configuration.Install for .NET Core. (.NET 4.0
version)
Use at your own risk
however, there are also oodles of installers that have this capabilities.
Lastly, this can also be done with powershell, P/invoke and I believe there was talk in github about releasing this source code however you will need to track that down and follow the trail yourself
To be clear, I follow the MVVM pattern, and I want to structure my project such that I can share my model code between a UWP app and a standard WPF app. The code I want to share has no UI. I don't relish the thought of finding new tools to replace the ones that I've been using for years that take care of certain tasks like logging, connecting to a document oriented database, etc.
I attempted to start writing a UWP wrapper around some code I already have and reference the model project directly. Visual Studio refused to let that happen, showing me an error message that says "Unable to add a reference to project 'ACK.Model'". The same thing happened when I attempted to put the model in a Universal Library and reference it from a WPF app. I'm not trying to share WPF code. Just the model layer that has no reference to UI libraries.
This is a scary proposition, because it means that if I want to do anything substantial I have to choose to either jump 100% to UWP or stay 100% WPF. NewtonSoft.JSON might have a universal distribution (ASP.NET MVC), but what about ElasticSearch.NET, and other tools needed to make important apps?
I found where the "Portable Class Library" project type was hiding. PCLs will allow me to share my code across WPF and Universal apps as that was one of the options. This solves the simple case of the Model part of my code, but I (still) can't use some of the libraries I want. There are still a large number of libraries that I need that do not have PCL available.
About a year later, with the advent of Visual Studio 2017 there is a more complete solution. If you target your libraries to .Net Standard then the library is compatible with both .Net Core apps and the monolithic .Net targeted app. The support for standard .Net libraries and APIs is fairly complete, as is the support for modern C# language features.
The general advice now is this:
Target .Net Standard for all libraries
Target the appropriate platform for your actual application. (UWP or WPF).
NOTE: if your library has to interact with C libraries or applications, you have to take extra care to make sure you load the correct version.
It appears that there is a solution, but it has to be adopted by the whole tool chain you want to use. When Microsoft introduced Windows Store apps in Windows 8, they also introduced a Portable Class Library (PCL). The purpose of the PCL is to share code between different parts of your application.
When you create a PCL in Visual Studio 2015, you can specify the types of APIs you want it to be accessible from:
Universal Apps
Mono
.Net Core 5
.Net 4.6
This of course, limits the APIs available to you but most of the ones you want to use are OK as long as it's not UI related. There are other limitations as well:
Your project can only be edited in Visual Studio 2015 or greater
You don't have access to special directories from the Environment variable (i.e. user Documents directory, etc.)
You can't link to a library designed for only one of your target platforms (i.e. libgit2sharp, etc.)
There's no way to browse the API for this subset--MSDN needs to get on the stick. MSDN has updated much of the API documentation, but it's still difficult to figure out what applies to your PCL
However, you can link any library designed for a single target platform to your PCL. It's not ideal, but it's better than nothing.
The ASP.NET MVC stack has been ported to using PCLs, so you can use NewtonSoft.JSON directly as well as any other of those libraries used by that application. However, there are several libraries that have not been ported.
This arrangement forces you to think about how you want to integrate better. The .Net Core 5 seems to be stable, but support is in it's infancy. The current generation of Universal Apps as of VS 2015 update 1 uses .Net Core 5 directly.
There are several features from Nuget that are not currently supported even though work is under way:
MS Build extensions (major changes to MSBuild and the project.json structure)
Install/uninstall scripts (related to the removal of the concept of install)
Content (related to install/uninstall, but work is in progress on this)
Content transforms (related to lack of install/uninstall)
I wish I had a more complete answer. But this is as far as I got once I discovered the PCL and how it evolved for the current infrastructure.
I'm in the process of creating a game creation toolkit that incorporates version control right off the bat. I want to be able to deploy a game as a Windows 10 app, or as a standard WPF app, but due to the libraries I'm using to integrate version control I need to create the editor as a standard WPF app. I had to be a bit creative in building the shared code and importing the correct libraries.
First, my project hierarchy:
Project.Model (Portable Class Library)
Project.Model.Versioning (standard C# library)
Mvvm.Toolkit (Portable Class Library)
Editor (Standard WPF application)
I want the core PCL to be able to load a project and deserialize the JSON encoded objects. The PCL did have access to System.IO, but surprisingly it is not the same as the one defined in the standard C# library. Here's how I had to fix things:
After adding the package reference to NewtonSoft.JSON, I had to change the target framework in the packages.config file:
<package id="Newtonsoft.Json" version="8.0.2" targetFramework="portable-net452+win81" />
All projects dependent on my Project.Model class had to install the `system.io.filesystem' package from nuget so that the System.IO.FileInfo etc. objects were the same.
While this is definitely not a panacea, it's also not a dead end. I'm sure there are more gotchas, but this will at least help with some of the problems.
a .NET Standard library could be used to share a Model-View-ViewModel architecture between a WPF project and a UWP project.
https://www.syncfusion.com/ebooks/xamarin-forms-succinctly/sharing-code-among-platforms
https://devblogs.microsoft.com/dotnet/announcing-uwp-support-for-net-standard-2-0/
I am currently trying to make use of DropNet to make a simple Modern UI application that will be able to access users' Dropbox accounts and upload files. However, DropNet apparently only supports .NET 3.5.
I've been trying to make the application utilize the .NET 3.5 runtime (rather than 4.5), but to no avail. I choose the appropriate .NET version like so:
Yet when I try to confirm the version, it shows a greyed out box like this:
This contrasts with non Modern UI apps, which show the appropriate version and give you the ability to change it.
When I try to obtain DropNet through NuGet, it throws up an error (as you'd probably expect):
Could not install package 'DropNet 1.9.3'. You are trying to install this package into a project that targets '.NETCore,Version=v4.5', but the package does not contain any assembly references that are compatible with that framework. For more information, contact the package author.
Is there any way to achieve what I'm trying to do?
You cannot make this work. A Store app project must target .NET 4.5, the only version of .NET that's compatible with the language projection that's needed to make .NET programs work on WinRT. In addition, the profile that permits WinRT programming (.NETCore as shown in the error message) is strictly limited and does not support references to .NET assemblies that target older versions of .NET.
I'm not aware of a 4.5 Store compatible wrapper for the DropBox api. You could possible take advantage of their generic REST api. Beware the general trouble you'll have making it work, and surely the reason that a 4.5 wrapper isn't available, Windows suspends a Store app when the user switches away from it. Which will interrupt a file transfer. A highly likely occurrence, the user won't have much patience with it.
I have a bunch of classes in a C# class library that I bought from a 3rd party company.
I want to use these classes and create my classes by inheriting them.
I have it all working on a .net 4 wpf application.
I want to then use these classes in my silverlight application.
What options do I have and which is the best option?
I want to use it in such a way that I can update the 3rd party company's DLL as they release their new version every month.
Just to re-inforce few points:
We have few options.
1. Link the classes (as an adding existing item but with a link)
2. Create interfaces and share them amongst WCF as a link class and let all classes inherit the interface
3. Use RIA service and let the web app create auto code to expose it to silverlight.
Are there other options? and if not then which one is better for the scenario that I am facing?
Thanks
It's worth noting however that the .NET platform shipping with Silverlight is not the same as the one shipping with the full .NET Framework.
It means that there is little chance that the third party assembly will be compatible with Silverlight, even if SL uses the same IL. If the third party assembly only references mscorlib or System.dll, it could be compiled as a cross platform assembly between SL and WPF.
However, in all the other cases, the differences between the SL and full .NET platform will prevent the assembly from being compatible with Silverlight.
If the third party software has anything to do with UI or network, if the software uses Windows API... etc.. it won't work in a Silverlight App.
This is the reason why a general .NET assembly can't be referenced from a SL project. However, there are cases when a SL assembly can be used in an general .NET project.
If the assembly perform computational and asynchronous task however, you could execute it on the server, and send back the result to the Silverlight app.
For instance it's a great option if the class Library generates reports, files or images.
What does the third party library do?
If you don't have the source code, you can't reference the class library in your Silverlight application (as you probably know already). It is not possible to use standard .NET libraries in Silverlight without recompiling, because Silverlight is a different framework and a different CLR.
You can use the library on the server and create some services to access the functionality.
I don't think there is any other way to achieve your goal, unless you get the source code which you can put into a directory with the name Shared. It will then be copied to your Silverlight application and compiled in Silverlight.
How do I create an app that is:
lightweight: I am guessing don't require .NET frameworks maybe?
portable: runs without installing and saves data in the app directory, so i can just move the folder or maybe even the exe?
this is just a personal experiment: i want to try create a simple todo list app that has the above attributes
I am thinking:
C#/WPF (but requires .NET framework, I can explore client profile thogh)
Appcelerator Titanium (i think this will be lightweight & good enough? I do not know if I can have a portable titanium app though)
It is almost portable if the target machines have .NET Framework installed.
NDepend is such a product, which is built against .NET 2.0 and runs fine on Windows Vista, Windows 7, and other Windows if you manually install .NET 2.0 before.
Personally, it is not hard to write an application launcher in native languages such as C++/Delphi to detect whether the target machine has .NET. If .NET is not yet installed, this launcher can display a warning or help install the framework automatically. (Even some installers allow you to do this.)
If you want to write it in C#, you either need the .NET framework or the Mono framework. Either way you need it. Thankfully .NET 2.0 is pretty ubiquitous.
By default, .NET uses xcopy deployment, so you can just copy the executable and any necessary DLLs around in a directory. It doesn't need to be "installed" unless you explicitly create external dependencies.
#jiewmeng, here i leave a few keys to build an portable application
If the application need save additional data like configuration files o data files , must be saved to the same folder of the exe application or an child folder of the application.
The application should not read/write configuration data to the Windows registry or in the %Appdata% folder.
avoid the use of external dependencies like ocx o dll files, that need to register in the system.
try to use an language wich makes native applications without framerworks dependence a good recomendation is use Delphi.
If you want to use .Net language, choose a version of .Net framework, that is in common use in most of the systems like the Microsoft .Net 2.0
Use Delphi, it's always portable and smaller