I am upgrading a Win8 application to UWP. .NET Native is causing a huge amount of issues, and a lot of WCF features that the application uses aren't supported.
Is .NET Native required for UWP applications? Can I just disable .NET Native in the Release build? Apart from some potential .NET Native performance improvements, will I lose anything?
The point is you are migrating to the .NETCore for the UWP, the subset of the .net framework, that leads to lots of your original codes can't fit into.
Are you migrating from a winRT store application or full .net framework based desktop app?
So far as I know the .NET CORE really cut-off lots of stuff from the Full. So if migrating from a Full .net desktop, that's really suffer.
.NET is supposed to increase performance, however it may create serious troubles, in some cases, e.g. if application extensively uses marshalling.
You can disable .NET native for Release in project properties.
Open Project Properties and select Build tab.
Set
Configuration: Release
Platform: All platforms
Untick box 'Compile with .NET native tool chain'
After you build the project, allow to run Certification Kit (WACK), and if is passes, take my congratulations. (I am not that lucky!)
Related
Can anyone help as to how to use the run time binaries found in the link below?
https://www.microsoft.com/net/download/windows
Basically, we are moving to .NET Core (we have been using .NET framework 4.0 for many years - so big shift as you can guess). I am kind of nervous to install .NET core on the production server (Windows Server 2012). Is it safe to install .NET Core on a server running .NET framework 4.0? If no, is there any way I can get the .NET Core runtime on to the server without installing them (kind of copying portal libraries) so that I can start with the beta testing of the app. Any help would be much appreciated. Thanks!
EDIT:
It is not duplicate, One of the main questions I had if I can use portable binaries on the server to run my app, without actually installing them (got the answer below, thanks again). Not sure someone down voted this without any reason. It makes the developers nervous to ask a question in StackOverflow. if they can mention the reason that would be great!
There are no issues when installing .NET Core and .NET Framework on the same machine. They are designed to allow them to be installed side-by-side.
However you do need to install the .NET Core runtime onto the server to allow the code to be run because the OS has native dependencies that need to be present. See this link for more information.
With .NET Core you can do framework dependent deployments (FDD) and self-contained deployments (SCD). FDD requires any shared assemblies to be present on the server i.e. System.* assemblies etc. but an SCD only requires the basic runtime/native dependencies. For an SCD your app deployment would include any .NET Core shared assemblies in it's deployment package.
You can read more about FDD and SCD here
Also there is more information about the native dependencies on different OS platforms here
We are using some old open-source .Net Framework libraries that depend on things that are not in .Net Core. Can Mono be used to fill in the rest of .Net Framework?
Specifically I'm thinking of creating a Universal Windows class library that includes everything in Mono (excluding some of the System namespace) that changes the namespaces from System.* to MonoSupport.System.*.
Of course, better approaches would be to re-write the library's code, use a different library, or be more selective in taking things from Mono. I was hoping to do this as a temporary measure.
(I want to use iTextSharpLGPL but it uses XmlTextReader, streams with .Close(), System.Security.Cryptography, etc.. The pay version of the library does not support UWP either.)
Edit: I gave up on this and rewrote my app to use Apitron. That worked great until I tried to deploy and found out they don't support .NET Native. I'm now waiting for some library to support PDF generation on UWP.
I do not think so. The following immediate reasons
Mono is a clone of the .NET Framework and therefore based on mscorlib ideas, while UWP is based on System.Runtime. Would require significant extra effort.
UWP apps - when released - are based on the .NET Native runtime. This runtime enforces some patterns in the library implementations (e.g. no reflection, no C++ implementation of types etc). Mono is also strong in AOT, but I think there are dragons.
Mono is a bad choice. Better is the microsoft referencesource for the .NET Framework as published on github.
The time you will invest in your plan will be so significant high, it is much better invested fixing it in corefx directly and wait for the next release of UWP to contain your fixes.
For your problem I would urgently recommend you to fix the problem as a submission upstream at iTextSharpLGPL by surfacing new methods and removing of close or maybe by just copying the MIT licensed XmlTtextReader. But I highly recommend you, not to mess around with crypto ;)
Can I use my own DLLs with a Xamarin iOS or Android project?
The reason I'm asking is because I want to compile dlls from Clojure CLR, and use them with my Xamarin mobile projects.
Currently the answer for this is 'No' - you cannot use your own existing assemblies but must instead recompile those projects as Xamarin.iOS or Xamarin.Android (MonoTouch or MonoDroid) libraries.
This is because the Xamarin twins are based on old Silverlight profile code and not on full .Net.
This situation is changing currently - Xamarin is rebasing on Mono3/.Net4.5 and Xamarin is working towards PCL support.
However, even with these recent changes I think it is still advisable to rebuild your assemblies for the specific platforms at this time.
I am in the process of creating a lightweight application in vb.NET, and was wondering if it is possible to create an application that uses some of the dll's within the .NET 2.0 framework, without actually using the framework itself.
For instance, can I take the dlls from the .NET directory that the app will reference (and only those dlls that it references), put them into a folder inside the app's directory, and then just change the reference path to that new location? That way, when the app is installed on pc's without .net framework installed, the dlls can just be zipped and copied over to the newly installed app directory.
This may all sound a bit confusing, just let me know if you need any more info.
It is quite unlikely that you'll be able to do that.
There is this thing called .net framework client profile for creating lightweight .net apps that do not need the whole framework but you still need to have that installed.
I would recommend using something like Delphi if you need a standalone exe that does not depend on anything.
There is concept of Client Profile in .NET 3.5 and .NET 4.
That is subset of .NET, smallest necessary fraction of .NET that client must have in order to be able to run .NET applications targeting client profile.
There is more detailed overview of the features you may use when targeting client profile.
Unless you move to .Net 4 or above, you need full framework on the client computers. Having said that, which OS are you targeting? Newer MS OS often come with .Net framework installed already.
I originally assumed that Metro style apps were managed (.NET) assemblies whether they are written in C# or C++ and I thought C++ for Metro style apps would be similar in concept to C++/CLI.
However, I now heard on a DotNet Rocks podcast that Metro style apps written in C++ are native. Nevertheless I understand that Metro style apps run on all three CPU architectures Metro is available for. How is this accomplished? Do Metro style apps come with different binaries and only one is chosen/downloaded? Or is it like on Mac OS X where one binary can contain code for different CPUs?
Code that uses only system or OS services from WinRT can be used
within an app and distributed through the Windows Store for both WOA
and x86/64.
from this MSDN blog page
If you go watch this BUILD video things should start to clear up -- http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-930C (A .NET developer's view of Windows 8 app development)
Basically there is a CLR (.NET 4.5) running. I didn't say a full CLR. WinRT from a .NET perspective is just a .NET Profile (sort of a way that they can layout the API differently exposing or hiding things). The new WinRT APIs use a new version of [gulp] COM, but it is optimized for use with .NET. I'm not 100% sure on the C++ angle. I suspect with C++, you have a few options. Compile for each platform (arm and x86) or compile to IL. Not sure if this helps you at all (I hope so).