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).
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
Can anyone help as to how to use the run time binaries found in the link below?
https://www.microsoft.com/net/download/windows
Basically, we are moving to .NET Core (we have been using .NET framework 4.0 for many years - so big shift as you can guess). I am kind of nervous to install .NET core on the production server (Windows Server 2012). Is it safe to install .NET Core on a server running .NET framework 4.0? If no, is there any way I can get the .NET Core runtime on to the server without installing them (kind of copying portal libraries) so that I can start with the beta testing of the app. Any help would be much appreciated. Thanks!
EDIT:
It is not duplicate, One of the main questions I had if I can use portable binaries on the server to run my app, without actually installing them (got the answer below, thanks again). Not sure someone down voted this without any reason. It makes the developers nervous to ask a question in StackOverflow. if they can mention the reason that would be great!
There are no issues when installing .NET Core and .NET Framework on the same machine. They are designed to allow them to be installed side-by-side.
However you do need to install the .NET Core runtime onto the server to allow the code to be run because the OS has native dependencies that need to be present. See this link for more information.
With .NET Core you can do framework dependent deployments (FDD) and self-contained deployments (SCD). FDD requires any shared assemblies to be present on the server i.e. System.* assemblies etc. but an SCD only requires the basic runtime/native dependencies. For an SCD your app deployment would include any .NET Core shared assemblies in it's deployment package.
You can read more about FDD and SCD here
Also there is more information about the native dependencies on different OS platforms here
I have some legacy .NET code that I would like to wrap with an API.
The code is a mixture of ASP.NET Webforms and .NET Framework 4.0
I'm hoping to use the new ASP.NET Core Web API and have created a new solution based on this framework and added the legacy code as existing projects.
Everything builds OK but when I try and call some of the legacy code I get the following error:
System.TypeInitializationException occurred HResult=0x80131534
Message=The type initializer for 'TreeManager' threw an exception.
Source=
Inner Exception 1: FileNotFoundException: Could not load file or
assembly 'System.Web.Extensions, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'. The system cannot find the file
specified.
This is the code I call:
TreeManager.LoadEvent += LoadTree;
public class TreeManager
{
...
public static event EventHandler<LoadEventArgs> LoadEvent;
...
}
I tried updating the legacy code to .NET 4.5.2 but get the same error.
I wrapped the legacy code with an API using ASP.NET MVC 4 API 2 and all worked well.
Is it possible to do this and, if so, what changes do I need to make?
First, you can choose to target either .NET Core or the full framework with a ASP.NET Core app. Just because it's "Core" doesn't mean you have to use .NET Core with it. If you're utilizing legacy APIs, you may be forced to run on the full framework.
If you need or simply want to use .NET Core, so that the app can be deployed outside of a Windows environment, then you'll need to migrate any APIs that aren't supported to alternative APIs or potentially rewrite functionality if no alternative API exists.
.NET Core 2.0 supports .NET Standard 2.0, which has a very large API footprint. Because of this, Microsoft opened up compatibility with legacy .NET Framework libraries and packages. However, no guarantees are made that you can fully utilize those libraries and packages. Just because you can add the dependency doesn't mean you can utilize all the APIs. That's likely what you're running into here. This particular set of APIs has a dependency on System.Web, which is not a part of .NET Core.
Recently, Microsoft has released some tools to make migration scenarios like this easier. First, there's the .NET API Analyzer, a NuGet package which will add Intellisense callouts to API calls that are not compatible with various targets. This will help you track down code that needs to be changed, and alert you when you're writing new code, that you need to do things in a different way than you might be used to.
Second, there's the Windows Compatibility Pack for .NET Core, another NuGet package that shims in support for a lot of older Windows-only APIs from the full framework. This can give you a bit of breathing room during your migration, reducing the amount if things you need to change, somewhat. Though, you are still encouraged to switch out this code eventually as well, eventually weaning your application off of the dependency altogether.
Finally, if none of this helps, you may simply have to find an alternative. That might require installing a third-party NuGet and rewriting some code to work with that instead of what you were using before.
No one ever claimed migrating was easy; it's always an uphill battle. If you don't have the bandwidth to do it now, simply target the full framework and call it a day. Otherwise, dig in and tackle it as best you can.
Using Visual Studio 2017 (RC), I am trying to setup a project that uses ASP.NET Core, but with the .NET 4.6.2 library.
This is a supported configuration:
Visual Studio will then create a default project; but it doesn't run:
This is without changing a single line in the project: the VC2017 template just does not work.
I tried the following:
- Different versions of the .NET framework
- x86, x64, AnyCPU
- Clear the NuGet cache
- 'Repair' options on Visual Studio's installer.
My understanding is that the error is a x86/x64 mismatch. But since I didn't change a single file from the template, there has to be something else wrong.
Installing ASP.NET Core on .NET Core works perfectly, so the problem is limited to using the regular .NET framework.
Any ideas?
I have the same problem too. But I just found the solution.
In ".csproj" I change some things:
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
<!--<RuntimeIdentifier>win7-x86</RuntimeIdentifier>-->
<RuntimeIdentifier>win10-x64</RuntimeIdentifier></PropertyGroup>
And I enable the 64-bit version of IIS Express.
I had problems like these when I restored stuff to a new laptop.
I mindlessly I copied files from my old profile directory to a directory with the same name, but that isn’t a profile directory on the new machine.
A part of this process involved a cloud backup service that my wife bought for me but that I never actually set up right. That also copied files to new locations without my paying attention to what was happening.
I still don’t know (yet) exactly how the machine keeps track of which versions of frameworks and tools to use in the various application directories, but I can report what I did that finally allowed me to create new .NET Core apps on the new machine.
I deleted everything in this directory that was older than today.
%USERPROFILE%.nuget\packages
Again, pretty mindless. I don’t know, (yet) if all that was necessary. Maybe just deleting one or two of the files/directories would have worked. Regardless, I was very happy to see that I could create and develop .NET Core apps on my new machine.
I am in the process of creating a lightweight application in vb.NET, and was wondering if it is possible to create an application that uses some of the dll's within the .NET 2.0 framework, without actually using the framework itself.
For instance, can I take the dlls from the .NET directory that the app will reference (and only those dlls that it references), put them into a folder inside the app's directory, and then just change the reference path to that new location? That way, when the app is installed on pc's without .net framework installed, the dlls can just be zipped and copied over to the newly installed app directory.
This may all sound a bit confusing, just let me know if you need any more info.
It is quite unlikely that you'll be able to do that.
There is this thing called .net framework client profile for creating lightweight .net apps that do not need the whole framework but you still need to have that installed.
I would recommend using something like Delphi if you need a standalone exe that does not depend on anything.
There is concept of Client Profile in .NET 3.5 and .NET 4.
That is subset of .NET, smallest necessary fraction of .NET that client must have in order to be able to run .NET applications targeting client profile.
There is more detailed overview of the features you may use when targeting client profile.
Unless you move to .Net 4 or above, you need full framework on the client computers. Having said that, which OS are you targeting? Newer MS OS often come with .Net framework installed already.