Why Oracle crash in .net standard of UWP but winform not? - oracle

I make a UWP program and I have to get data from a Oracle database of my customer. My customer gave me a dll which he made. I tried and found that made by .net framework of 4.6.2 so that UWP do not support it. I suggested him rewrite the dll by UWP, but he refused that. So I have to find a way to make it works in UWP.
I googled and found that if I make a .net standard dll for the bridge between UWP and .net framework that I can make it works in UWP.
Finally, I made a .net standard dll, in the .net standard I reference the dll my customer gave.
But after I debugged my .net standard dll, all code I wrote works without error, but the dll my customer gave threw an error:
"The type initializer for 'OracleInternal.Common.ProviderConfig' threw an exception."
I wonder if there is something wrong with the dll of my customer. However,it is so strange that if I reference his dll in winform, all is OK, but only in .net standard it crashed. What's more, the code what I wrote in winform/.net standard is the same, only declare a class and run a void, just two-line code.
My customer knows nothing about UWP and I also know nothing about Oracle.I don't want rewrite whole project by WPF just for this, that's such a huge work!
Would you please teach me what's wrong with that and how to solve my problem. Thank you.

I wonder if there is something wrong with the dll of my customer.
In short, there's no wrong in your customer's .net framework dll. You just misunderstood the .NET Standard. Your .NET Standard library worked in winform, that's because your .NET Standard library adds reference to your customer's .net framework dll. This .net framewrok dll works well in .net framework applications, but it doesn't mean that the APIs in the .net framework dll are supported in UWP, even if you've used your .NET Standard library to wrap it. I suggested that you could read Introducing .NET Standard for more detailed information.
For your question, if your customer does not want to rewrite their dll and you're also not able to write a library to make it work in UWP. You could make a WCF. In WCF, you could directly add reference to your customer's dll. Then, you could use this WCF service in your UWP directly.

Related

For a Xamarin Forms application is the PCL architecture becoming obsolete?

I have a Xamarin Forms application that uses shared code. It has three projects, shared, iOS and Android. These are very similar to those which are created when I create a sample application from the Xamarin new project menu.
I am looking to have the application updated and published by a company that has experience in doing this but I am not sure I understand a couple of the work items that have been suggested to me:
Currently, architecture is PCL which is becoming
obsolete.
Move to .NET standards
Could someone explain to me what these work items might mean?
Yes, it will become obsolete at some point. .NET Standard is the evolvement of the PCL libraries.
With PCL libraries you could target a number of platforms and only the functionality that was supported for all targeted platforms were available to you. Associated with each combination of platforms were the profiles. A profile was identified by two or three digits. Notable ones for Xamarin were 111 or 259. Read more on PCLs here: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/pcl
.NET Standard is a specification of the APIs associated to it. If a platform supports a certain version of the .NET Standard, you are guaranteed that all APIs are available. This way, you can simply target a specific .NET Standard version and each platform that supports it will support your application. The .NET Standard specification has gained a lot of traction and is already more cross-platform than a PCL ever was. Most of the creators of NuGet packages are supporting it already and also Xamarin/Microsoft has replaced the PCL with a .NET Standard library in their templates. Read more on .NET Standard as a concept here: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
So, if you have the possibility it might be wise to start moving to the .NET Standard library. That is, if you want to keep supporting your app and need new libraries coming in. If your app is fine the way it is, you can probably keep going with the PCL for a while. Converting is basically: change the csproj structure to the new structure. Retarget your library to netstandard and reinstall all the libraries you have installed, this time to download the .NET Standard compatible version. The last step might be a bit of a pain.
A good resource on converting might be this by Adam Pedley: https://xamarinhelp.com/upgrade-pcl-net-standard-class-library/
There is also a solution to do it automatically: https://smellyc0de.wordpress.com/2018/03/23/automatically-converting-pcl-to-net-standard-2-0-project/
.Net Standard is a specification for a set of APIs. and is the way things are going. With it, comes a higher level of range of .Net SDK APIs you can use, plus most 3rd party Nuget packages will support it. They can support a wider range of platforms. by targeting .Net Standard. Thus you will get access to a larger number of nuget packages. See https://learn.microsoft.com/en-us/dotnet/standard/net-standard
I put my Forms Apps into a .Net Standard library, because it easier to unit test. There is a Xamarin Forms nuget package you can use for testing, which means a lot of UI paths can be verified in code, where previously you had to do it on a device, perhaps with automated testing. https://github.com/jonathanpeppers/Xamarin.Forms.Mocks
Upgrading an existing PCL project to .net standard is a pain. Any more, I just create a new Xamarin Forms solution with the same name/root namespace, with the app as .Net Standard, then copy files over.

Handle windows lock/unlock events in .net core

In the .Net Framework there is an event that, when handled, you could log was lock/unlock events on an account. It is this one:
Microsoft.Win32.SystemEvents.SessionSwitch
I can't find this in .Net core. Does anyone know what the equivalent in .Net Core is?
As this event is platform specific, it probably wouldn't the part of .Net Standard, so you can't find it in .Net Core. According the APIs of .Net, they do not have plans for introducing this class.
So, you may try to create a platform-specific library with SessionSwitch code, but that wouldn't run on other platforms rather than Windows, and put your general logic into .Net Standard library so you can use that either from .Net Core app and .Net Framework app.
Other way is to use Mono, which contain such events in it.

Class Library (Legacy Portable)?

I have one PC with Microsoft Visual Studio Community 2017
Version 15.2 and it has a project template for Class Library (Portable).
Another PC with Version 15.3.1 has a template for Class Library (Legacy Portable). Are PCLs now legacy ?
Any current news on what I should be using instead ?
Well, "should", I won't say that without seeing exactly what you're doing but yes, PCLs are now "legacy", the new way is .NET Standard and .NET Core.
Please note that legacy does not mean "will stop working" so there shouldn't be a need to do anything as of yet.
To figure out which kind of .NET Standard version you want to target to get-out-of-legacy, you can consult the compatibility list on the .NET Standard web page.
Specifically, you likely want to consult the other matrix on the same web page, the .NET Implementation Support matrix and figure out which platforms you want to target, then create a "Class Library (.NET Standard)" project targetting the highest .NET Standard version you can get away with.

Nemerle for Windows Phone

I just started to study Nemerle. Since this is .NET language, I wonder, is possible to use for Windows Phone development? Does Visual Studio support it well?
Nemerle compiler uses System.Reflection.Emit for assembly manipulations. Then it can create assemblies same CLR version only.
I know only one reciepe for build WP assemblies: ildasm ncc.exe, fix all references to WP framework and ilasm it again.
This may not be possible, since Windows Phone runs a subset of the full .NET Framework which is closer to the .NET Compact Framework.
Looking at this page (translated from Russian) it looks like Compact Framework support is something that is/was planned for Nemerle version 2. However that article was written before Jetbrains acquired the project, so objectives may have changed.
Having said that, much more recently (Feb 2013) one of the Nemerle developers spoke about their difficulties in getting Nemerle to support other frameworks. So perhaps it is on their agenda after all.

Windows CE project with libraries problem

I am developing a Windows CE application which uses some libraries provided by other parts of our company.
When I deploy my application on "My Computer" (.NET compact application running on standard PC), everything works, but when I deploy to the device, the application hangs when trying to use methods from the library. The system also hangs. My Visual Studio 2008 sometime hangs, but sometime throws an exception "TypeLoadException: Could not load type from assembly Culture=neutral, PublicKeyToken=nu".
I couldn't include .NET Compact framework 3.5 because the image wouldn't compile, so I am using version 2.0. I use Visual Studio 2008 with deploy .NET framework option.
Most probably the problem is with version of the library you are using. Please cross check it.
Hope this link will help you.
I'm a bit confused.
First of all, what are the libraries "provided by other parts of [y]our company" build against? Are they Compact Framework assemblies (they must be)? What version of the Framework were they build against? Reflector can tell you this if you don't know.
Second, why can't you compile it with 3.5? What sort of errors are you seeing? The code should be 100% forward compatible, so if it won't build, there's a red flag going up.
Lastly, what version of the CF is installed on the target hardware? FOr example, are you trying to push a CF 2.0 app to a device with CF 3.5 already installed? If so, do you have an app.config file that provides the framework compatibility options so it knows it can run your assembly?
The problem was that libraries were compiled with for 3.5 target framework, and the application which uses them form 2.0 framework. In that case, 3.5 framework wasn't depoloyed and application would stop working as soon as call to the library methods was made.

Resources