We are currently migrating our projects which are developed on .NET472 to .NET6.0. We had used EF6 for Oracle DB connection and it has now been done via Oracle.Manageddataaccess. Now after we changed the underlying projects, we are getting an error as mentioned later. We found there were two feasible solutions on net but we had some issues:
Change from Oracle.ManagedDataAccess to Oracle.ManagedDataAccess.Core:
This needs application to be moved EFCore, but we can't do this since we can't move all our code from EF6 to EFCore now.
Add reference to Microsoft.NETCore.Portable.Compatibility:
I have added that but still we are getting same error.
The error is as follows:
System.TypeLoadException: 'Could not load type 'System.Security.Principal.WindowsImpersonationContext' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.'
Here are the references which I have already tried:
Type Load Exception for WindowsImpersonationContext (Stack Overflow)
You must add reference to mscorlib (Stack Overflow)
Related
We are referencing Serilog Nuget package in our .Net 6 application. Then we use AssemblydependencyResolver.ResolveUnmanagedDllToPath to load the application assembly as plugins. It can't find the kernel32.dll which is refereced via Serialog.Sinks.SystemConsole.
Our questions are:
Is this because Serilog is not supported with Net 6?
Is it a 32bit or 64bit version of kernal32.dll getting loaded from Serilog?
Follow-up for question 2:
When loading 32bit kernel32.dll, we get a bad image format exception, which means our application is 64bit and trying to load a 32bit assembly.
When replacing the 32bit with 64bit kernel32.dll, we get the following error:
Unable to load DLL 'C:\kernel32.dll' or one of its dependencies: The specified procedure could not be found. (0x8007007F) at System.Runtime.InteropServices.NativeLibrary.LoadFromPath(String libraryName, Boolean throwOnError) at System.Runtime.InteropServices.NativeLibrary.Load(String libraryPath)
I am creating a project windows runtime component(with c#), and I want to use embedded DB so I added Firebird-2.5.2.26540-0_x64_embed and .net component NETProvider-2.5.2-CF. Every time when I am performing any action on FBcommand and FBConnection i am getting error "An unhandled exception of type 'System.NotSupportedException' occurred in FirebirdSql.Data.FirebirdClient.dll"
I can't use terget framework because its WinRT(c#) project...
Note this answer is actually by #cincura.net on the Firebird .NET mailinglist. I am just posting it here for completeness:
The ADO.NET stack is not available in WinRT, hence you cannot use any
database access. The CF version didn't helped either.
See How should a Windows 8 Metro Application connect to a central database? and How might a Windows 8 Metro app handle back end database access? for potential solutions.
Why I cannot create Type Provider as *.exe file with [<TypeProviderAssembly()>] and [<EntryPoint>] inside?
When I try to reference such TP using #r #"d:\TP\bin\Debug\MyTypeProvider.exe", I see the following:
test.fsx(3,1): error FS3031: The type provider 'd:\TP\bin\Debug\MyTypeProvider.exe' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'MyTypeProvider' which cannot be loaded or doesn't exist. Could not load file or assembly 'file:///d:\TP\bin\Debug\MyTypeProvider.dll' or one of its dependencies. The system cannot find the file specified.
I need to have a type inference runtime in separate process, because it should be 64bit (unlike 32bit VS process). But I want to pack all things into one file, reference it from VS and start as external process.
Perhaps there's some good underlying reason for always looking for DLLs instead of EXEs, but I suspect this may be an arbitrary limitation.
I can get things to work in FSI if I supply the assembly's full name to the TypeProviderAssemblyAttribute constructor (e.g. [<TypeProviderAssembly("MyExe, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null")>]), but IntelliSense doesn't work and I can't use the TP from other projects. Consider filing a bug with the team - but it would probably help if you could justify why you need an EXE instead of a DLL for your scenario.
So I've create a solution with multiple projects... one is for my website, the other for my data. I've added the reference and everything seems to be working just fine. Until now...
I recently created a model.edmx for a table and a stored procedure. When I trying and create a variable of that model, I get this error:
The type 'System.Data.Objects.ObjectContext' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
I'm assuming this is because I'm using multiple projects, I just don't know how to fix this!
Ah... just like having to add the reference to the other projects within the solution, I had to add a reference to the System.Data.Entity using that same right-click "Add Reference" dialog.
The project where you are trying to create a model object needs to have a reference to System.Data.Entity (as the error states).
In my ASP.NET MVC application, I have the following setup:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;extras"/>
I have referenced assemblies located in the extras folder in the views and they have worked perfectly (using <%# Import Namespace="myNameSpace" %>).
My questions
What happens when that line is called?
Where is the assembly loaded?
Why is it that I can't overwrite the assembly located in the extras folder that contains myNameSpace with a newer version? (I get an error saying that the assembly is "open" in another program)
Is there a way to overwrite the assembly with a newer version without having the application restart?
1) Import doesn't actually do anything at runtime. It's a compile-time convenience that just lets you refer to types using their unqualified names such as Environment instead of System.Environment.
2) The assembly is loaded using normal assembly probing rules. The CLR checks various locations before these private probing paths so it's important to keep that in mind. If you reference a strong-named assembly and expect to find that assembly in a private probing path, an assembly with the same strong name (name, version, public key, etc) in the GAC would be preferred. This can sometimes lead to unexpected behavior and is usually caused by hard coding an assembly version in your AssemblyInfo.cs and forgetting to update it.
3) Once loaded, an assembly cannot be unloaded without unloading the AppDomain. But ASP.NET uses "shadow copying" which means assemblies are copied to a temporary path before being loaded. This should leave the original assembly unlocked and able to be overwritten. Off the top of my head, I am not sure why you'd be getting the error about locked assemblies. In a normal Windows application, this would be totally normal and expected. But ASP.NET is designed so that you can overwrite content, code, assemblies, etc while the application is running, which leads to #4.
4) In practice, no. Because an assembly cannot be unloaded, there is no way to upgrade an assembly without the web application being restarted. Technically speaking, you can load multiple versions of an assembly but this would not give you the desired results. Any compile-time references would still reference the old assembly and you'd get all kinds of invalid cast exceptions if you tried to use the new assembly. But as I said in #3, with ASP.NET upgrading assemblies is supposed to be as simple as replacing the files and should happen automatically. You shouldn't have to restart IIS or worker processes manually.
The following links may be of interest.
How the Runtime Locates Assemblies
Best Practices for Loading Assemblies
Shadow Copying Assemblies
Unloading Assemblies - Suzanne Cook
UPDATE
After reading a bit more on shadow copying, I think the reason you might be seeing the issue of locked assemblies in the extras folder is that ASP.NET probably only specifies the "bin" folder for shadow copying.
I think this is the same as a using statement in C#, it basically means that the namespace's classes are now available to be used in yoru page.
The assembly will be loaded into memory probably by the aspnetwp.exe process
If the assembly is currently being used you will get this error message
A restart is the safest way I know of doing this, you could use dependency injection or late binding to achieve the same result. I would jsut wonder why you would want to switch an assembly while the application is running?