I have a number of Sitefinity sites, running on 3.7.
I am looking to hear pro's / cons for updating to version 4. Why would, or wouldn't you?
Edit: forget the cons. Can anyone list convincing pro's that will make a difference for them? I'm not just looking for a re-hash of the feature list, thanks.
Edit2: I still welcome comments once SF4.0 is RTM.
I work for Telerik:
You cannot currently update a Sitefinity 3.x web site to Sitefinity 4.0. Sitefinity 4.0 is not yet released. It currently only exists as a CTP release. During the first week in August 2010, there will be a BETA release of Sitefinity 4.0, but it is not intended for production web sites.
Telerik will not create a migration path for these early pre-release versions of Sitefinity 4.0. There are no tools available to migrate your Sitefinity 3.x web site to an early CTP or BETA build of Sitefinity 4.0. Furthermore, Telerik will not create tools to allow you to migrate content from these early builds to the official build of Sitefinity 4.0
The RC release of Sitefinity 4.0 is tentatively planned for October 2010. This will be the first 4.0 release where a migration path is available. Early adopters can begin to test migration of their existing web sites using this RC release. In October I would be glad to discuss pros and cons.
Until then, the con of updating to 4.0 is that you've reached a dead-end. The CTP and BETA releases of Sitefinity 4.0 are intended only for experimentation. Telerik is using these releases to gather early feedback.
Be sure to read more about the licensing issues with Sitefinity 4.
Sitefinity community is not liking the pricing announcement
Related
I have a multi-project solution that contains a data layer on .Net Standard 2.1 and a WebAPI on .Net Core 3.1. Currently, I have no plans to upgrade to .Net 5.x (Note: Core is removed in 5.x naming convention) because it is not LTS - that will be .Net 6.x. So, I will upgrade to 6.x when it comes out.
In one of my data layer solutions, the NuGet Package Manager is recommending that I upgrade Microsoft.AspNetCore.Identity.EntityFrameWorkCore from v3.1.8 to v5.0.2. It seems like the major version is moving in lockstep with the .Net major version (Note: 4.x is skipped in order to avoid confusion with the venerable .Net Framework 4.x). Should I follow the advice and upgrade?
Specifically, will this cause any problems with the .Net Core 3.1 WebAPI project? Generally, can I do this for other Microsoft.* packages that recommend upgrading to a 5.x version?
I bit the bullet and upgraded all of them. Everything works flawlessly and I am glad that I did it. There were a few breaking changes that needed to be dealt with. I recommend checking Microsoft's breaking change log here:
https://learn.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio
We upgraded our project to EF 6.1 because there was a serious query bug in 6.0 and now we are nearing our production release date and EF 6.1 is still RTM. I was gambling that EF 6.1 would hit full release before we did, and I lost.
Am I allowed to release my application using EF 6.1 RTM? Are there any licensing considerations I need to be aware of since it is RTM and not fully released?
This is the official information about EF licensing at codeplex:
https://entityframework.codeplex.com/license
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
We're currently developing an application that is using EF Code first (EF June 2011 CTP).
My first question is: Is it worth trying to upgrade to use a later version of EF?
Secondly, if so, does anyone know the steps involved to upgrade - when I try to install the NuGet package for EF 5.0 - beta 2, I end up with issues as the target framework is still 4.2.
Many thanks,
James.
The CTP is long time dead with no other version coming because all that stuff is currently part of .NET 4.5 beta and EF 5.0 beta. You must upgrade to those two and the upgrade will consist of re-targeting application back to .NET 4.0 / .NET 4.5, removing all dependencies to your current EF version and re-adding those dependencies for .NET 4.5 / EF 5.0.
Some time ago I wrote a blog post on this: http://blog.3d-logic.com/2012/04/11/entity-framework-zombie-a-k-a-microsoft-entity-framework-june-2011-ctp/. There is a number of issues with CTP 4.2 because of technical challenges related to shipping a .NET Framework library out of the .NET Framework (like 4.2 target). Move to .NET Framework 4.5 that contains the same feature set as EF 4.2 + bug fixes and has a go-live license. Use EF 5.0 on top of it and you will be in a better world.
Thanks for all the responses.
My main issue is that we rely heavily on ENUMs in our implementation of 4.2 code first. I attempted to migrate the project to 4.5 but ENUMs are not supported, and there is also an issue with table per hierarchy (which is easy to fix). The next move will be to upgrade to VS11 and use 5.0 - but this is a big undertaking.
#jwsadler:
Enums are supported by core EF libraries released as part of .net Framework 4.5 (e.g. System.Data.Entity.dll). To make enums work with CodeFirst/DbContext you do need EF 5.0.0 package from NuGet (use Install-Package EntityFramework -pre (-pre is important)). You need VS 11 for this since Visual Studio 2010 cannot be used to create applications that target .NET Framework 4.5. Note that when installing the nuget package on Visual Studio 11 the target version of the .NET Framework set for the project is taken into account. If you target .NET Framework 4 you will not be able to use EF5 features like enums or spatial.
I'm very interested in using 4.0 framework and also the Entity Framework 4.0. Currently .net 4.0 is in CTP and I'm EF 4.0 is in CTP Preview. I will not be coding for a few more months, but i'm not so sure that either .net 4.0 or EF 4.0 will be RTM by then.
My questions:
1) Regarding Microsoft Products, is CTP usually stable enough for production?
2) If I use CTP initially and then want to upgrade to RTM when it's available should i expect a lot of pain in the upgrade? or is RTM usually "backwards compatible" with the CTP?
Often beta and CTP products aren't even licensed for production use, regardless of stability. You should check what the licence says before anything else - assuming you care about legality, of course.
There will often be a fair amount of change between CTP and release, but less between beta and release, and even less between RC and release.
Btw, .NET 4.0 is in beta 1, not CTP.
For .NET 4.0 neither the CTP nor the currently available Beta 1 of .NET 4.0 is licensed for production use.
Microsoft's previous behavior has that Beta 2 is normally under their Go Live licensing which allows for some production use. There is a comment from Somasegar on this blog post that says that they will release a Go Live version "at a later date."
I can only speak for .NET 4.0 and not EF, but we have been writing production code with it for a while and while there were some breaking changes between CTP and Beta 1 there do not look to be as many breaking changes between Beta 1 and Beta 2.
As others noted, both the beta and CTP licenses do not allow deployment on a prod server.
On the other hand, as MS will delay the release of both VS 2010 and the .net fx 4.0, the release candidate versions will have their licensing changed to allow for use in production.
More info here.