I am creating a fresh Mono for android application using http://xamarin.com/monoforandroid
I selected Mono for Android Application using Visual C# option.
My Android target version is :
I went to references of the project and tried adding my pre existing dlls (made in .NET 4 Framework)
and I got this error:
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
The problem here is that you're trying to reference a .NET 4 DLL from a project that isn't .NET 4. Mono for Android uses its own profile for .NET, which is very similar to that of Silverlight (but not exactly the same). While it's possible that adding a DLL compiled for a different profile will work, it's very risky as you will probably run into problems at runtime where your app will crash, due to something being missing from the Mono for Android profile.
The best answer right now is to create a Mono for Android class library, link in the appropriate files from the library you want to use, and reference that. This will give you compile-time checking that you're not using anything unsupported by the Mono for Android profile, and help keep you more sane in the long run. I have an old blog post up here that talks about how to link files across projects.
That said, in this case you're in luck because someone else has already done that last part for you! Check out this fork of Json.NET which provides versions for MonoTouch and Mono for Android.
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
It's not particularly strange - that dialog box was written by Microsoft, with its own project types in mind. It sounds like Mono for Android doesn't have the same options available.
I strongly suspect you'll just have to use a version of JSON.NET targeting .NET 3.5.
(Having said that, Mono for Android claims to support "dynamic language features" which sounds like it should be targeting .NET 4. Odd. I suspect the fix is the same though.)
Related
I get the following problem every time I try to run my mobile application:
System.DllNotFoundException:
'SQLite.Interop.dll assembly:<unknown assembly> type:<unknown type> member:(null)'
To put this in some context:
I am developing on Xamarin.Forms [4.3.0] (in this case running the build on Android 9.0 x86). The client-side library runs on .NET Standard 2.0 and I have installed System.Data.SQLite.Core (1.0.112) from NuGet.
When you look up my problem, you will find people saying to put the SQLite.Interop.dll's into the x86/x64 folders. But when looking for these files there are none for .NET Standard at all, only for .NET Framework. I tried using the SQLite.Interop.dll's from the precompiled statically-linked binaries from the .NET Framework 4.6 version.
Screenshot of the project structure
Same error though.
Unfortunately, it is not possible for me to switch the SQLite library as I am porting a desktop version to mobile which uses this lib.
if they have not made a mess in the classes and functions you need to port you can use "Microsoft.Data.SQLite", there is a difference but is not as far away from usable as the crazy nonsense you need to do with "SQLite-Net-Pcl"
There are TONS of posts, blogs, articles, etc... explaining all of this confusing stuff with regard to .Net/.NetCore/.NetStandard and I have read many of them.
Here is the issue, I have a Windows 10 UWP app and I need to reference a library that I created. I first created the library as a NetCore library but I could not reference that from my UWP app (which is confusing because UWP uses .Net Core but the .Net Core library I created assumed this was for ASP.NET?).
So, then I tried to create the library as a PCL library and targeted ONLY Windows 10 UWP (which it then forces you to Windows 8.1 because they are the same). With this type of library I am confident I would be able to reference it from my UWP app but it caused me to lose too many .Net namespaces that I could not get the library to build.
Finally, I then selected the link, in the project properties, to target the .Net Standard instead. I selected .Net Standard 1.4 and suddenly, I had all the namespaces I needed available to me and I was able to build my library. I am also able to successfully add it as a reference to my UWP app.
However, I am getting the following 6 exceptions and they don't tell me too much about the root cause so I can fix it.
So, my main question is, can you reference a .Net Standard 1.4 library in your UWP app? Second, any ideas what these exceptions mean?
Thanks!
EDIT - I have uploaded both csproj files here:csproj files
Okay, I found that answer but it was based mainly on this answer which I did not see before posting my question due to search terms (I have literally spent over a day searching and trying to find an answer).
Answer that helped:
Here is a summary:
.NetStandard 1.4 is supported by UWP.
By default, VS 2015 Update 3 template for a UWP project imports Microsoft.NetCore.UniversalWindowsPlatform version 5.1.0. I am sure the VS 2017 template will start off with a newer version, 5.1.0 is fairly old. So, based on the answer linked above, I updated (using NuGet) to the newest version allowed by VS 2015 Update 3 which at the time of this answer, is version 5.2.3. There is a 5.3.x version but it requires VS 2017.
Finally, I modified the project.json in my UWP project to import the netstandard1.4 framework. It looks like this:
"frameworks": {
"uap10.0": {
"imports": "netstandard1.4"
}
And, with those simple steps, I can get the UWP project to build and those 6 errors above go away.
Hope this helps!
I've recently had to some work in Unity that required classes only available in the later versions of .NET, which Unity does not yet support. I managed to download the very few scripts that I was missing and added it to my project and it seems to work fine. What I wanted to know is why can I not just take the entire .NET source and shove it into my projects? What are the implications of doing something like that?
EDIT: The scripts that I have added so far was the generic version of WeakReference as well as any dependencies that it needed (Contract in System.Diagnostics.Contract).
EDIT EDIT: I basically want to know why I can't simply just the C# class files found in the later versions of .NET to Unity, which uses an older version of .NET. Is it a software issue? Is it a hardware issue? Is it because Unity's system components were built in correspondence with the earlier version of .NET?
SHORT ANSWER:
Install the Visual Studio Tools for Unity (it should automatically get installed when you install Unity), when you do you can tell your .csproj in the "target framework" drop-down to target the special version of .NET Unity uses and you will only be able to compile dll's that have methods and types that Unity supports.
LONG ANSWER:
It is because Unity does not use the installed version of .NET on your computer. Unity uses Mono, and a very old version at that. This allows unity to be ran on multiple platforms and OSes. Because of that you can only use features that are in the supported version of Mono.
However, if you look at their roadmap the alpha build you will see
Scripting: C# Compiler Upgrade
Upgrade Mono C# compiler against our
current .Net 2.0 and 2.0 Subset profiles. Note that this is an upgrade
of the C# compiler only, not the full Mono runtime
Then further on in the "research" phase
Scripting: .NET Profile Upgrade
Upgrade .Net profile to 4.6 enabling access to the latest .Net functionality and APIs.
UPDATE:
You can get a experimental build that uses the 4.6 profile from the stickied post here.
Here are the notes for the 5.6.0b5 beta release
For this release, the Editor and the following players should be working:
Windows, OSX, Linux standalone
iOS with IL2CPP
Android with IL2CPP and Mono
Other platforms are known to not work yet, and are probably not worth installing.
Managed debugging via Visual Studio Tools for Unity or MonoDevelop is not supported in this release. If you want to use VSTU for
editing please use the special build linked at the bottom of this
post.
The compiler targets the C# 6 language.
The compiler by default will still target the .Net 4.6 framework profile.
Known issues
The Android/Mono build does not work properly with managed code stripping. Please disable managed code stripping for now.
For some projects, the Windows standalone player can crash on Windows 8.1. This is intermittent, so we would love to see any crash
reports or data about this
A similar question was answered before here. Like I described in your other question, you can "inject" newer stuff and use them, but sooner or later they'll backfire (e.g. can't compile to particular systems, can compile but cannot be published in whatever mobile store, surprisingly slow execution, huge builds, etc. Worst case your project will be compromised).
If you really cannot refactor the project you are working on and you feel you must use 'up-to-date technology', bear in mind the injected classes code must be data objects, means, not at all related to GameObjects.It is also adviced to derive from ScriptableObject when and where possible.EDIT: But I'd recommend what I told you earlier (refactor) or what the linked answer describes ('export' the code incompatible with mono/.net2.0 to an external dll and use it from there)
I'm trying to use the Protobuf C# Port that was developed by Jon Skeet's on a Unity project, but I keep getting errors when I try to build and run a stand alone. I have copied over all the .dll files into the assets and things run smoothly while I'm running unity from developer environment, but as soon as I compile and build I get an error about a "filename unkown".
error image
I haven't managed to find a solution because it seems that most people run into similar issues using Marc Gravell's version of Protobuf. I'd like to stick to the version that I'm using now since I will be working with several languages for this project.
Any help is greatly appreciated.
-- Solution --
It turns out that I had to go into Edit > Project Settings > Player and change the NET version from 2.0 Subset into 2.0
I often find type initialization exceptions occurring because of project reference issues. The two most common causes:
Building your application against a newer version of .NET than the library being referenced (e.g. Protobuf library may have been compiled against .NET 4 while the application is being built against .NET 4.5). You could try resolving that by recompiling the Protobuf libs against the same .NET version as your project.
The compiler assumes a reference is present, but at run time it is not. You can fix this by adding a reference to the specific library (in this case the .NET library with the RegEx object, which is usually System.dll)
How can I check what objects, tools, variables, anything... are used from .NET 2.0 in a C# application.
How can I get a C# application run without .NET 2.0 ?
UPDATE:
sorry, I didn't clarify enought. Here's my situation: I have developed a pretty simple application in C#: embeded browser which displayes static webpages with an option of searching inside of these html pages. I'm using simple textbox, buttons components for this.
The application will be distribuited for people wich have very old PCs, even with windows 95. I would like the app to be runable on it, or at least on win 98, without telling the people to install .NET 2.0, as the users don;t really have PC usage skills :) .
I'm using a dataGridView as well.
You can have a look at this : http://www.remotesoft.com/linker/
"The mini-deployment tool puts
together the minimum set of CLR
runtime files and dependent assemblies
that can be simply copied to a single
folder on a target machine, and your
application runs as if the whole
framework is installed. Since the
installation is isolated into a single
folder, there will be no conflicts
with future .NET installation. When
linking is used for the dependent
assemblies, it will further reduce the
file size."
You may need to clarify a bit more.. do you want the app to run without .Net at all? Or you want it to run in .Net 3.5 without .net 2.0 bits?
If its the latter, then simply don't reference assemblies that are compiled in .net 2.0 (check the properties on the reference you have added). If its the former, then its really not feasable. Yes its possible, but it means deploying parts of the framework with your app, but then, you'd be deploying all the bits, including the 2.0 bits.
Your're question really needs more information though, it doesn't make much sense currently. Sorry. =)
To make sure it runs without .NET 2.0, compile it with the .NET 1.1 compiler.
But this seems like not a good idea. I'd recommend revisiting your requirements.
Win98 wasn't shipped with .NET. Using .NET v1.1 won't get you much more platform penetration than .NET 2.0, if any.
IT looks like windows 98 supports the .net framework. See this answer for details:
OS Compatibility for various .NET Framework versions
You cannot run a .NET application (i.e., that uses the CLR) if you haven't installed the corresponding .NET Framework binaries (i.e., that contains the CLR) directly or indirectly.
Period.