For along time we've been using legacy components originally compiled using PostSharp 2. But recently we tried to upgrade our main framework to use PostSharp 4 (we want to try out some of the new features) but now every application referring to legacy components will crash. The legacy components cannot be re-compiled for legal reasons, so that is not an option for us.
Is it possible to have new code (in .Net 4.5 and using PostSharp 4.x) work together with legacy components (build on .Net 3.5 and PostSharp 2.x)?
Related
We currently have a whole suite of applications targeted to framework 4.6.1. These run across our estate, including 400+ remote POS units.
I see that framework 4.6.1 went out of support in April 2022. I need to understand how best to move forward back on to a supported platform.
The obvious issue that comes to mind is security patches. Now that 4.6.1 is unsupported no further security patches will be available potentially opening up our network to vulnerabilities.
This gives me my first thought of installing framework 4.8 on our client machines and letting our applications, still targeted to 4.6.1, run under 4.8.
Will this mean that we will be covered by security patches installed to the 4.8 framework as the runtime will be 4.8, can we get away with NOT retargeting our projects?
The second thought is to install 4.8 on our client machines and re-target the applications to 4.8. We have various different code sets that run together as larger applications but there is also a cross-over between classes within these applications so re-targeting and maintaining compatibility will be a challenge.
Also, how do I identify any regressed functionality between 4.6.1 and 4.8?
Finally, should I look at .NET 5.0?
Our company has multiple applications that are .Net Framework 4.8 and we also are growing the number of applications that are .Net Core 3.1.
We have written a whole library of NuGet packages (in a private repository) written in .Net STANDARD 2.0 that are currently consumed by both the 4.8 and Core 3.1 applications mentioned above.
Standard 2.1 offers many new language features, such as Nullables, and we want to start to migrating our NuGet packages over to Standard 2.1, but obviously need to continue to support those applications still on .Net 4.8 (which can't consume Standard 2.1).
Obviously we need to branch our source code, but what is the convention for publishing two almost identical NuGet packages, one written in 2.0 and the other 2.1?
NuGet supports multiple-target-frameworks for a package. Please refer to doc to learn more.
I wanted to follow up on a post from last year ("EF5 , Widows Forms , Dragging a chield entity from project datasource into a GridView creates only 2 columns").
I believe the problem described with EF5 is still true and the solution found (use EF4) continues to be the only reasonable answer.
Before I upgrade to VS2012, I wanted to check whether anyone knows if there is any problem using EF4 in VS 2012.
Anyone with experience on this?
VS2012 requires .NET Framework 4.5 which is an in-place update. This means that once you install the .NET Framework 4.5 it will be always used when running .NET Framework 4 or .NET Framework 4.5 apps. This also means that you will be running EF5 even if you target .NET Framework 4 in VS (targeting is only a design time thing which prevents from using APIs that were not available in the targeted .NET Framework version while at runtime the app will use the version installed on the box).
With regards to the problem you are reporting - take a look at this bug report on the EF codeplex site as it apparently contains a solution to the problem
I have a NuGet package for a library that is currently implemented only for .NET 4. But I have ported library code to support various platforms (WinRT, SL5, WP8) so ideally I would like to package it as a portable class library (PCL) to simplify the maintenance. But the library is using LINQ to XML (XELements etc.) that requires targeting .NET 4.0.3 and installting .NET 4.0.3 on a client machine.
So I have a dilemma regarding how to target plain .NET 4. If it was not about NuGet packages and I had a control of the user base I could simply state as a prerequisite installing .NET 4.0.3 runtime. However, I don't want to limit the user base in any way, so it looks like I will have to have two versions of the library: portable that targets .NET 4.5, SL5 and WP8 and non-portable targeting just .NET4. What's silly is that both libraries will have exactly the same code since LINQ to XML is of course supported in .NET 4, it's just PCLs that don't have such support when targeting .NET 4.
My first question is whether this seems to be a right strategy? The alternative would be to take away all XElement-dependent code from PCL and have it in non-portable parts, but this does not seem right because the code will be exactly the same for all libraries.
The second question is whether it makes sense to target .NET 4.0.3 from a PCL at all: if I have separate version targeting .NET 4 will users that have .NET 4.0.3 runtime installed gain anything from getting a PCL rather than plain .NET 4 version? I know .NET 4.0.3 has other improvements but those don't affect my library.
Yes, I think the best thing is to create two versions of your library, one targeting .NET 4 and another portable library that targets the other platforms you support. Use source file linking so you don't have to have two different copies of your source code, just two different Visual Studio projects.
You only need one NuGet package though. Put the .NET 4 version in lib/net40 and the portable version in lib/portable-net403+win8+wp8+sl5 (or whatever combination of platforms you decide to support). Then NuGet will install the right one depending on what a project is targeting. NuGet 2.1 or higher is required for this to work for the portable version.
In reference to the question about .NET 4.0.3, it's about giving the consumers of your library flexibility. The people using your library are using it to create applications. Supporting .NET 4 may not be as important to them as it is to you. By supporting .NET 4.0.3 in the portable version of your library, it means that if they choose to require .NET 4.0.3 in their apps, then they will be able to use your library from their own portable libraries and more easily share their app code across platforms.
I need to know if it is possible to start using the latest version of EF (4.3.1) with VS 2011 without having to install these CTP components as stated here.
I had these components installed but I removed them and since then I can't add a new edmx file to .net 4 targeted project; it complains about missing reference to System.Data.Entity.
Do I need to re install VS 2011?
After I removed and reinstalled Visual Studio, I still couldn't get red of the error, so I used process monitor to log what Visual Studio is doing with System.Data.Entity as a path filter, turned out that Visual Studio was reading from
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\policy.4.0.system.data.entity v4.0_0.0.0.0__b77a5c561934e089\policy.4.0.system.data.entity.config
which had binding to the
System.Data.Entity.dll v 4.2.0.0
once I cleared the file VS was worked like charm.
The CTP uninstall left this out.
Yeah should work with no issues using .net 4, however theres a list of known issues when using .net 4.5. You dont need to re-install vs to get version 4.3.1 of entity framework, simply install it from the nuget package gallery and if you are using .net 4 it all seems to just work.
Issues listed when installing EF4.3.1 on .net 4.5 include those listed below.
Known Issues with Entity Framework 4.x and .NET Framework 4.5
Entity Framework 4.1 thru 4.3 included additional data annotations in the
System.ComponentModel.DataAnnotations namespace in the EntityFramework assembly.
In .NET 4.5 these annotations were moved to be part of the .NET Framework in the
System.ComponentModel.DataAnnotations.Schema namespace of the
System.ComponentModel.DataAnnotations.dll assembly. If you are using EF 4.x and targeting
.NET 4.5 this results in two data annotations with the same name in different assemblies.
Because the annotations in the .NET Framework are in a different namespace we were not
able to use type forwarding to avoid this conflict.
It is possible to use EF 4.x on .NET 4.5 but we recommend using the latest pre-release
version of EF 5. If you are not using the affected data annotations there is no impact
on your code. If you are using the data annotations in a C# project you can use the extern
modifier to ensure your code uses the annotations from EntityFramework.dll
(http://msdn.microsoft.com/en-us/library/e59b22c5(v=VS.80).aspx). If you use the new
annotations from the System.ComponentModel.DataAnnotations.dll assembly in .NET 4.5
they will not be processed by Code First.
The affected annotations are:
Column
ComplexType
DatabaseGenerated
DatabaseGeneratedOption
ForeignKey
InverseProperty
MaxLength
MinLength
NotMapped
Table