I have a project for Azure Functions that has .net standard 2.0 as target framework. This project uses System.Data.Sqlclient to insert and fetch data from a db. It works fine when I deploy it to azure.
To be able to test my code I have created classes in this project that handle the business logic and is setup in the static function that azure executes.
My problem is that when I try to create a class library that is to contain unit tests, I always get an exception that says: System.Data.SqlClient is not supported on this platform. The code runs fine before that. I have tried both .net core and .net 4.6.1 as target framework but no luck.
It worked when I created a new class library with .net core 2 as target. Don't know why it didn't work the first time so unfortunately I cannot tell what went wrong the first time.
Related
I recently migrated a dotnet framework v4.7.2 WCF service with the upgrade-assisstant tool to NetStandard 2.0. the project successfully migrated and compiled, BUT I couldnt start the service either from visual studio nor dotnet cli.
the Error I get from dotnet cli tool is :
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found.
AND the error I get trying to start the service from visual studio, solution explorer -> right click on wcf project -> debug -> start new instance is:
A project with an output type of class library couldnt start directly.
P.S when the WCF service was still dotnet framework v4.7.2 I could easily start the service doing the above mentioned procedure in visual studio.
As I know .net 4.7.2 is the lowest real version that supports .netstandard 2.0 In this link.
You can back it up and upgrade to 4.7.2 to try it out.
WCF server APIs are not supported on .NET Standard or .NET Core/.NET 5+, so there's no good way to migrate such an app forward.
Upgrade Assistant tries to figure out whether a project should upgrade to a library or an exe based on the previous project type. For this project, Upgrade Assistant guessed it was a library since there was no traditional main method and it wasn't a web app or some other project type that the tool understood as executable. Regardless of whether it upgraded it as a .NET Standard library or as a .NET 5 exe, though, it wouldn't work because WCF server APIs are only supported on .NET Framework.
It might be nice if Upgrade Assistant alerted you to that early in the process so you knew upgrading wouldn't work for this type of project. I thought it had a feature like that, but it must have missed for this specific project. You could provide feedback on the tool's GitHub page (https://github.com/dotnet/upgrade-assistant/issues).
As far as how you can actually upgrade WCF server stuff, you'll need to re-architect using a different technology like ASP.NET Core, gRPC, or CoreWCF.
Environment: VS2019 - ver16.6, Windows 10 pro 1903
I followed this link from Microsoft team to create a VS2019 solution with .NET Standard 2.0 library project and a dummy .NET Core Console app as a startup project. In that solution, I also followed this EF Core official tutorial to create a SQLite db (called MySQLiteDb.db) that gets created in the root directory of dummy .NET Core Console.
Afterwards, I referenced that .NET Standard library in one of my WPF Full Framework project to perform some db operations. For that I copied MySQLiteDb.db from the above project into this WPF project and set its Copy to output directory action to Copy if newer with Build Action as None. Now, this WPF Full Framework app works fine and performs multiple db operation on MySQLiteDb.db.
But when I do the same as above on a Microsoft VSTO Add-in project by referencing the same .NET Standard library, I get an inconsistent behavior: For example, half of the time the app successfully performs a data insert but about half of the time the app throws the following error on the data insert. And there is no data validation because this test db has three simple text columns with no unique keys/index etc. Question: Why this inconsistent behavior on VSTO project but not on WPF project while both are .NET 4.8 projects. And how can the issue be resolved?
Error:
Inner Exception 1: SqliteException: SQLite Error 1: 'no such table: MyTable'.
Why this inconsistent behavior on VSTO project but not on WPF project while both are .NET 4.8 projects.
You need to make sure the add-in is using the .net framework 4.0 runtime (CLR) which corresponds to the .net framework 4.8, not CLR 2.0. You can use a configuration file to specify the runtime version to use by the host application, see Application Configuration Files for more information on the runtime element.
I'm mainly PHP dev, recently forced into .NET.
I have a solution with 2 projects:
one has data connection to one database and is a .NET Core project
another one has data connection to a second database and it is .NET EF 4.7 project.
I want to create a console app that will allow me to work with both databases. I need those 2 projects as they already have all models and connection defined and work well on their own. I need to be able to connect to both databases, and fetch some data to output in a console.
So far I've created a third project, Core 3.0. I managed to use the 1st project data connection, but I can't possibly work out how to use the EF 4.7 project connection. I'm getting this error:
The ADO.NET provider with invariant name 'System.Data.SqlClient' is
either not registered in the machine or application config file, or
could not be loaded. See the inner exception for details. --->
System.ArgumentException: The specified invariant name
'System.Data.SqlClient' wasn't found in the list of registered .NET
Data Providers.
I've tried reinstalling EntityFramework, checked app.config (provider string is there), checked if EntityFramework.SqlServer.dll is in dependencies - everything seems ok.
Is this even possible? Can the 3rd project be a Core 3.0 project? Someone mentioned that I should use .NET Standard Class Library to work with both projects, but Class library is not a console app. Please point me in the right direction...
Both 1 and 2 should be .NET Standard projects. The third should target either .NET Core or the .NET Framework.
I am afraid you can't "use" a .NET Core project from a .NET Framework project and vice versa. That's why there is the .NET Standard.
You may want to consider breaking out parts of your existing projects into class libraries that target .NET Standard. You can then reference them from any app that is compiled against a version that is compatible with the .NET Standard version you are targeting.
I have a Web API application created using .Net Core 2.1. A controller from within this web application calls a Business Layer Class library that I also developed using .Net Core 2.1. So far so good...
The .Net Core Business Class Library references a commonly used .Net Framework 4.6.1 Class Library that we have also developed. This library is primarily used to communicate with Azure service bus queues.
As a result this commonly used .Net Framework Class Library in turn references and makes use of the Microsoft .Net Framework Assembly, Microsoft.ServiceBus as shown in the line of code below.
MessagingFactory messagingFactory = MessagingFactory.CreateFromConnectionString(configValue);
As you can see the line of code above that is within our commonly used .Net Framework Class Library passes a string value (i.e. configValue) to a static method that exists within the Microsoft.ServiceBus assembly.
However, whenever the line of code above executes I get the following Error:
An unhandled exception occurred while processing the request.
TypeLoadException: Could not load type
'System.Web.Configuration.WebConfigurationManager' from assembly
'System.Web, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'.
Out of interest I added in the following line of code which I get the same error:
string configValue = WebConfigurationManager.AppSettings["connectionString"];
Clearly, the issue is that the System.Web .Net Framework assembly isn't loaded.
However, given that the web application is .Net Core then how can I make this web application load the underlying .Net Framework assembly that the commonly used library requires?
Solutions Considered - (Unsuitable)
I had a similar issue before which was easily solved by installing the necessary NuGet package but on this occasion I have not been able to find such a package.
Our team has another Web API application in .Net Framework which calls this commonly used class library without issue however this is not an option and we need to keep the current Web API application based on .Net Core.
I also considered having the commonly used library re-written as a .Net Standard 2.0 Class Library but this given the size of the library this would not be a realistic approach and it won't necessarily address the underlying issue.
Other Possible Solutions
Load a Web.config from within the .Net Core Web API application that contains a configSections section referencing the assembly System.Web. I tried this but it didn't work which I'm sure if I just didn't apply all steps necessary. Is this possible and if so any suggestions?
Is there an alternative way to load the .Net Framework assembly from within the .Net Core Web API?
Sacrifice using the commonly used library and find an alternative (sample) code base that provides similar functionality (i.e. make use of Microsoft.ServiceBus to work with our Azure queues) but that is either .Net Core or .Net Standard based. But similar to the .Net Standard solution above I am unsure how much functionality would need replicated and also unsure of a starting point. Thoughts?
Thanks!
I had the same issue and after investigating i found that my azure function app run time version is 2.0 ~ and according to documentation version 2 is .NET Core 2 and function app version 1.0 ~ is .NET Framework 4.7 . and my visual studio function app project have .NET Framework 4.6.1 . So, I just had to change my function app version to ~ 1.0 .
In a Nutshell
If you have visual studio function app in .NET Core 2.0 then only use function app version 2.0
If you have visual studio function app in .NET Framework 4.7 then only use function app version 1.0
I have a stateless .Net Core services running in Service Fabric. In my services, I reference a class library that targets .Net Framework 4.7.1. I deploy the application via VSTS and one of the build steps updates the app version for services with changes.
https://learn.microsoft.com/en-us/vsts/build-release/tasks/utility/service-fabric-versioning
Everything works fine except that changes are always detected for the class library's dll-file. Even though I haven't changed anything in the code library! This causes the build step to bump the version of every single service. Not just services that actually has updates.
The logs looks like bellow. 'MyClassLibrary.dll' is a .Net Framework Class Library that I haven't touched the code in.
2018-03-12T11:39:51.1989307Z Searching service 'MyServicePkg' for
changes...
2018-03-12T11:39:51.2247570Z Searching package 'Code' for changes...
2018-03-12T11:39:51.9878149Z The file 'MyClassLibrary.dll' has
changed.
2018-03-12T11:39:54.3850926Z Updated package 'MyServicePkg\Code'
from version '1.0.0' to '1.0.1'.
I'm aware that the check for changes in the code package is binary comparison. So the binary obviously change when the project is compiled. However, I don't know why. I also have code libraries that targets .Net Standard 2.0 and they don't cause this issue as changes are only detected when I actually have touched the code.
I'm also aware that it is possible to manually omit files that shouldn't update from the application package https://stackoverflow.com/a/34886586 However, that is not an option since the deployment chain is automated.
So I have the following questions:
What causes the binary for a .Net Framework class library to change?
In what way does it differ from a .Net Standard class library?
How do I work around it so my services only updates when I make real changes? Port from .Net Framework to .Net Standard?
Some insight in the matter is greatly appreciated.
By default, the compiler will create different outputs even if you made no changes. Use the deterministic compiler flag to ensure builds with the same inputs produce the same outputs.
So, you need to specify /p:Deterministic=true argument in MSBuild Arguments.
The simple way is using Azure Service Fabric Application build template: Create a new build definition > Select Azure Service Fabric Application template, then you will find, there is /p:Deterministic=true /p:PathMap=$(Agent.BuildDirectory)=C:\ in MSBuild Arguments of Visual Studio Build task.