I'm using the current master branch of Python.Net 3.0 from GitHub, on Python 3.10, on Windows 10.
I wrote a test DLL in .NET 5 that uses System.Data.SqlClient to perform a single call to a SQL Server instance as a proof-of-concept. I configured the runtimeconfig.json file to correctly identify the .NET version (see https://github.com/pythonnet/pythonnet/issues/984#issuecomment-778786164). But when executing the code, it throws a System.PlatformNotSupportedException.
So I rebuilt the C# code for .NET Framework 4.8, adjusted the Python code accordingly, and the same code executes fine.
My theory is that there is some kind of .NET Framework dependency embedded in the SqlClient library that usually works fine inside of .NET 5. But wrapping it in Python.Net somehow breaks this. Does anyone have a good explanation for why I'm seeing this behavior?
Related
I intend to build simple Winform application just to allow user to automate their file creation and store the last filled form in a file to keep it for next run.
thus, I'm not interested in creating installer for this simple Winform application. I expected to only compile it to .exe and let it run on other computers.
I develop the application using VS2019 community with target .net 4.6.1
It won't run on computer with Windows 10 with only .net framework 4.8
We are not able to install framework 4.6.1 since it says an earlier version of .net framework is already installed.
Should I recompile my application with target .net framework 4.8?
Can't I compile my application to run on any computer which at least has 4.6.1 or newer? without installer.
(I don't really understand the .net framework backward compatibility truly mean)
my application uses:
library of user32.dll for SetForegroundWindow function
to create .ini file
Finally it works. Even compiled to target .NET 4.6.1 still work on .NET 4.8 computer actually.
The issue is because my application is targeting to another application using interope COM interface, while the license is not sufficient for the user to allow COM interface.
we notice it when we finally create a pure simple windows form, then step-by-step compiling while adding each feature.
Sorry Every Body for this silly case. And my special apologize to evry1falls for spending your time.
I'm thinking to change this Question or delete it. because it is not the issue at all
The Actual Issue is:
I created Windows Form Application starting from a blank Project. And I don't know that the .NET Unhandled Exception is not activated by default.
When created from Windows Form Project Template, the Unhandled Exception message shown.
I created another Question about it: Here
i was able to get the sample asp.net embedded powerbi to work with my reports
now i have to migrate it aspnetcore
i was hopeful when i saw this post - seeing that someone was able to get it done
Embed Power BI Report In ASP.Net Core Website
so i:
started a new project with the aspnetcore
installed the powerbi package
now when compiling im getting this warning:
Package 'Microsoft.PowerBI.Api 2.0.11' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
i searched and couldnt find a powerbi package that was specific to aspnetcore
is there one? will there be a conflict crossing cores? or does it not matter?
UPDATE:
4.6.1 powerbi package does indeed work with aspnetcore 2
but looking forward to a powerbi package specifically coded for core
As you can see this is just a warning, not an error. That warning appears because .NET Core 2.0 applications can use some Nuget packages which target .NET Framework 4.6.1 (or less). However, this inclusion might fail if the referenced .NET 4.x package contains some API not included into .NET Core/.NET Standard 2.0
So, my advice - try to run your application. If it works well at the first glance - then, most probably that PowerBI package does not contain any not supported APIs and will work well further. If it fails right at start - then you will need to wait for the release of the new version of that package which targets .NET Standard 2.0.
I have a .NET library (dll) of helper methods specific to installing my product, that targets .NET 4.
However, the "main" WIX project is targeting .NET 3.5 (as specified in the documentation) (meaning it runs on the 2.0 runtime). It has custom actions that call into the above 4.0 dll.
When running the generated MSI, i get "BadImageFormat" exceptions, when the WIX runtime (running on 2.0 runtime) tries to load my 4.0 dll.
If I had direct access to a .NET 3.5 .exe, I could convince it to load a 4.0 dll by using the trick in its app.config.
However, the WIX runtime is loaded (by msiexec), as far as I can tell from the stack trace, through Interop.
Does anybody have a suggestion on how I could get this to run?
PS. I also tried making the "main" Wix project target 4.0 directly instead of 3.5, but then my setup dialogs will just fail to show.
I don't know how you have this setup in wixsharp, but in Visual Studio WiX has a project template for C#/DTF custom actions. It automatically includes a CustomAction.config that you can use to put SupportedRuntime elements in to achieve what you are trying to do.
Take a look at WIX and Custom Actions
The BadImageFormat exception means that you are attempting a cross architecture call somewhere in your calling sequence, 32-bit to 64-bit or vice versa. That might be a consequence of getting the incorrect framework, but not necessarily!
I have an application that consists of a client-side application and a WebApi website.
My client-side stuff is targetting .NET 4 so that I don't have to insist that users install .NET 4.5. My website, however, is entirely under my control, so I'm targetting .NET 4.5.
There is one shared assembly, which I use for data access. It uses Entity Framework 5.
When I build the client application, the DLL used is version 4.4.xxx, whereas when I build the web application, the DLL is 5.0.xxx.
Up until now, I've been able to run the client application with no problems, and I've also been able to run the web application, again without problems.
However, I've now re-created my web application project from scratch (*), and suddenly I can't run it. I get a YSOD saying "Could not load file or assembly 'EntityFramework, Version=4.4.0.0 ..." at the point where my data-access assembly is first invoked.
Now, it's perfectly clear what that error means - it can't find the v4.4 DLL as used by the data-access assembly - but I don't understand why that's a problem with my new project when it wasn't a problem with my old project. As far as I can see, the same DLLs are referenced in each project.
(*) I should explain why I'm re-creating my project. I originally created the project in VS 2012 RC, and then later upgraded to the release version. Although this supposedly upgraded my project, I've had a few problems with it, and have also noticed some differences v. a newly-created project. So, to be on the safe side - and hopefully circumvent those other problems - I'm re-creating it from scratch.
So, my question: why is this suddenly a problem, and what can I do to resolve it?
Is the code depending on the assemblies set to require the exact version? If so, you will need a publisher policy for the EntityFramework assembly or bindingRedirect for the referencing application (web project).
I have developed a Windows application in the 4.0 framework. After deploying my application I have tried to install it in a Windows XP SP2 system, but when I try it I get some kind of requirement error. So I decided to change my application from 4.0 to the 2.0 framework so that it can be installed in any windows OS. Before that I tried with 3.5 and 3.0 but the framework's setup size exceeded 200mb, so I chose 2.0 because it already comes along with windows xp or later. The problem I am having is while changing my framework from 4.0 to 2.0 i'm getting reference problems with system.core and system.linq so now I cant build my project. What needs to be done to fix these reference errors?
The problem is that System.Linq, for example, didn't exist in .NET 2. If you are using anything that required System.Linq methods (such as LINQ or any extension methods), you'll have to rewrite that portion of your code to use .NET 2 only options.
Personally, I would just target .NET 3.5sp1 or .NET 4, and include the web installer, as this is a small addition to your deployment (the 4.0 web installer is under 1mb - many installers include a way to just package this instead of the full framework). Most systems already have .NET 3.5sp1 (and many have 4.0), so the effort to include this in your deployment is typically far smaller than trying to rework your application to avoid it.