The company I work for wants to integrate our system with another company's .NET SDK, however I have run into an issue where our system is .NET 7.0 and their SDK requires .NET Framework 4.8. This company will not share details about what parts of their SDK require .NET 4.8, so I can't just use reflection for those specific libraries/assemblies.
I've been trying to find a way to integrate with them and I learned about reflection. How exactly can I use reflection to load in an older version of .NET Framework and also have that SDK use it? I've seen a number of posts about using reflection to load in older versions of other libraries/assemblies, however I haven't seen any for .NET and the most similar ones to my case are very dated and for WPF. None of the questions involved having some external SDK use that specific assembly version either, so I'm not sure how to progress from here.
Usually a .NET version is equal accross all libraries, so it makes sense there is no additional information.
There's 3 solutions to incompatible versions:
Create an 'adapter' built in .NET 3.5 that fetches the required data and then outputs it in a format that your .NET 7.0 application can use.
Downgrade your own application to the supplier's version. This is actually preferred if you're just developing an extension or other limited-in-scope functionality.
Get the supplier to commit to a .NET upgrade, and close your ticket as 'won't fix'
I am developing an app with .NET Standard 2.0 project as core project, so bumped into the fact, that I am not sure how I should (can) handle the famous easy-to-access-and-setup approach with MvvmCross.
Search for Cirrious.MvvmCross.Plugins.Sqlite plugin in Nuget doesn't return anything (apparently it's been a while and it's not supported).
SQLite-PCL doesn't seem like sound .NET Standard-ish, plus there is a whole bunch of different packages with similar name (and with no any close reference to MvvmCross actually) appear.
There is also a reference to sqlite-pcl-net plugin in release notes for MvvmCross 5, but it also "doesn't smell" Mvx-y.
So, what's going on with MvvmCross SQLite these days? What should I use? Any ideas?
There used to be an official MvvmCross Plugin for SQLite but it was dropped sometime around early 2017 because the plugin was redundant. SQLite is probably the most popular database used in MvvmCross applications, but there is nothing in MvvmCross requiring this. You are still free to use Realm, Entity Framework Core, etc.
You should be using the praeclarum/sqlite-net version of SQLite since Android 7.0. Here is the NuGet feed for the package. This version supports .NET Standard and PCL. Other forks are not maintained as much, or stopped working reliably on Android due to the changes to the way SQLite was changed in Android 7.0.
I've also recently provided another answer to a question asking how to add SQLite to an MvvmCross application since the plugin was removed. I provided some sample code for Android in the answer. The old MvvmCross SQLite Plugin source code is also still available.
I am using Sqlite ADO.NET provider 2.0 in my c# application .net framework 4.0.
Question1: Does this .dll come with a back up Database functionality?. If the suer wants to backup, looks like I have to get the source code and write my own backup feature.
Or is it already provided and I just need to use it?
Question2 :
I tried downloading a recent version of Sqlite ADO.NET provider(line 3.5/4.0)
from this website
http://www.sqlite.org/download.html/
sqlite-dll-win32-x64-3071300.zip
After attaching the dll as reference, it still says
Version v2.0.50727.
Description: ADO.NET 2.0 Data Provider for SQLite. Is this correct stable version or is there a recent one to be used.
Thank u
For Question 1: The ADO.NET provider isn't meant to have a backup capability. That's something the RDBMS software should have. ADO.NET is just a tool used to simplify communicating with the RDBMS.
- However, SQLLite backups are documented at http://www.sqllite.org/backup.html
For #2 I don't see a question - just a statement that you got a warning from Visual Studio. BUT based on what I'm seeing, you will get an error. You're trying to use an SqlLite provider for .NET 3.5 or above, and your .NET project is set to 2.0. Either upgrade your app to 3.5 or above, or look for an older .dll to download and use.
As a general rule of thumb, in a .NET project, you can use .dll files specified for an older version of the Framework, but not .dlls specified for newer versions.
I'm starting up a rather large-scale open source server project written in C# which targets both the MS.NET and Mono platforms. However, I realized that Mono only has limited support for LINQ to SQL, and no support for the Entity Framework at all.
Two ORMs I have considered are NHibernate and SubSonic. However, I have no idea how either will operate on Mono 2.8 (which is what I'm targeting).
So, can anyone recommend an ORM that will run on Mono 2.8, or happen to have used some of the aforementioned ORMs successfully under Mono?
Thanks in advance.
Mono supports:
NHibernate - Free, open source, proven and tested. Easy to configure. My personal favorite.
db4o - Free if you open-source your own project. You have to license it for commercial apps. Much less well-known than NHibernate.
siaqodb - Available for Mono 2.4 and up. You have to pay $185 for a license, but the redistributable engine is royalty-free.
In choosing from this list, I'd suggest NHibernate. Lots of help is available out there for it and it works fabulously.
Another very interesting one I have come across recently is Vici CoolStorage. It even supports Mono (MonoTouch specifically) on the iPhone.
You sure NHibernate doesn't work on Mono? You should be able to use the same Assemblies at Mono. Another option is to download it's source and compiling it. Check this page https://forum.hibernate.org/viewtopic.php?f=25&t=951909&start=0
I can't seem to get my application up and running on my dev server and I'm not sure why.
I have compiled my code in VS 2008 with a target framework of 3.5. I am using 3.5 mainly because I have implemented LINQ rather extensively. Compiling and runs local without any problems.
The hang up is that my server only has the 2.0 .Net framework and upgrading to 3.5 is apparently not going to happen.
I was under the impression after doing some research that as long as I was trying to execute compiled code the server would not need 3.5 installed.
Today I am trying to publish to the server and I can't get past this error in my WEB.CONFIG
Configuration Error
Parser Error Message: Child nodes not allowed.
providerOption name="CompilerVersion" value="v3.5"/
EDIT ADD ON QUESTION:
I have seen some posts about possibly setting my references to "copy local" which might allow me to run on the 2.0 server. Thoughts?
You are right in that 3.5 runs on the 2.0 CLR, but 3.5 contains libraries and if you have used any of those, you're out of luck unless you install 3.5 on that server.
There are plenty of options for a 3.5 program to not run correctly on only 2.0, so I'd consider downgrading the program, or upgrading the server.
Note regarding copy local. Even if you copy all the 3.5 libraries that your app uses, there is no guarantee it'll work and most likely it won't. Even so, distributing the libraries with your app is expressively prohibited by the .NET license.
Since you have stated you use LINQ, the only legal way to get your app running is to install the 3.5 license.
Or, you can rewrite your app using only 2.0.
I'm pretty sure that LINQ is one of the things that makes 3.5 a requirement. A lot of the other things, like lambda expressions etc. are just compiler trickery.
Because System.Linq is a 3.5 feature, the framework is required to be that version.
A good way to determine would be to change the target framework to 2.0 and see if it builds.
Code compiled against 3.0 or 3.5 may run on the 2.0 framework, but only if you do not use any libraries that are specific to the 3.0+ framework. One good way to find what's causing your code to fail is to switch your target to 2.0 and change things so that it compiles. Since one of your target installations is .NET 2.0, you are going to have to write .NET 2.0 code; this is not unique to .NET. In the past, writing an application that executed in both Win95 and WinNT involved extra work for the developer to carefully make sure the appropriate API was used.
Technically, 3.5-targetted code can run on 2.0 with no problems, but there's some gotchas you have to watch for. If anything accesses something that is unavailable in .NET 2.0, that will fail. This doesn't happen when the application starts, it happens when the application tries to make the call. I tested this by making a console application that does a little bit of output, then tries to display a WPF window. The output is made, but the application throws an exception when it tries to display the window on a machine with nothing but .NET 2.0.
Another gotcha is that VS 2008 actually comes with the .NET Framework 2.0 SP1, and there are a few types and methods in SP1 that are not in the normal 2.0 Framework. Visual Studio will not flag these methods as unsafe.
Finally, if this is a web application, the default web.config file for 3.5-targeted projects is very different than the web.config file for 2.0-targeted projects. Make sure you're distributing a compatible web.config. This is likely the problem you are encountering. A cheap workaround might be to change your target to .NET 2.0, copy that web.config, and use it in this case. Keep in mind that if you are using any 3.0+-specific language features or types your code will still fail, but this should get you past the web.config.
You're not going to be able to run code targetted to 3.5 on the server unless you get 3.5 installed on it.
The problem isn't your code, rather that the required libraries will be missing.
This is not possible. Although the CLR has not changed (like it did between v1.1 and v2.0) The libraries have. You cannot run a 3.5 app that doesn't have the 3.5 fraework installed. All of the Linq features are made possible by the 3.5 framework.
One error is in Web.Config. The published Web.Config is setup to allow compilation from .NET 3.5, which is the reason it includes build provider information.
Beyond that, your code won't run. By using LINQ, you're referencing assemblies that don't exist in .NET 2.0.
I was just going to leave a comment by my rep is not quite there. I agree with the crowd so far and believe that lassevk's answer is the best so please give him the rep for that. One this I wanted you to know about though is that once you install 3.5 on your IIS server (6 or better). When you go to the IIS Manager and right click on your website to access the ASP.Net tab. You will see AFTER the install of the 3.5 Framework that there is no 3.5 option available. It will still show it as 2.0.50727. Don't worry about that, it will still work just fine. Because of this inconsistence (thanks Microsoft) some confusion has been caused. Actually I think this is why you may have thought that 2.0 would run your 3.5 code just fine. Hope this helps and anyone please edit this so it makes more sense.
You can may use of some C# 3 features whilst targeting .NET 2.0. Its the language features which by the time its compilied to IL will run on the 2.0 CLR regardless of whether that CLR is part of a 2.0 or higher framework install.
Hence you can use anonymous types, extension methods and Lambda expressions but as soon as you do things like LINQ you then need external libraries that are part of 3.5
If you are only doing LINQ to Object you could add the LINQBridge to your distribution.
Another problem you can run into is if you are shipping a web application that includes the source code, such as code behind files, in line code and .cs in the App_Code folder.
You can end up shipping C# source code which compiles on the developement machine with C# 3 compilier present but fails to compile on a server only equiped with C# 2. In this case you can't use any new language features either.
What's worse is that specifing the .NET 2.0 framework as the target in the Visual Studio doesn't stop you using C# 3 language features. You get no warnings that such syntax will not compile on a 2.0 machine.
Hence if you are shipping such a web app, you'll need to compile pretty much everything first.
You can just copy over the 3.5 dlls onto the server. You can absolutely run 3.5 code on a 2.0 server.