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?
Related
I wrote a plugin for Microsoft Dynamics CRM 2011. It runs alongside a bunch of other plugins written by different contractors targeting different versions of .NET.
My plugin targets .NET 4.5. I recently installed .NET 4.5 on the CRM web servers. If a user causes my plugin to fire (Create/Update of account), the plugin runs fine without any issues.
However, when an updates comes from a different plugin, the following error is thrown:
Method not found: 'System.Delegate System.Reflection.MethodInfo.CreateDelegate(System.Type)'
The limited stack trace we've received from the contractor reporting the error says it's occurring within my plugin. I am using Ninject, which I think is the likely culprit. I am guessing that somehow my plugin is being run in a .NET 4.0 environment where this method does not exist.
I am not very familiar with the way CRM runs plugins. Outside of the web servers, do I need to install .NET 4.5 on any other machines? Could this be related to a .NET 4.0 plugin indirectly calling my .NET 4.5 plugin?
Even for crm-2013 Microsoft says that you should use .net 4.0. I think that you are right on the mark when you say that it's the interaction between 4.0 and 4.5 in your plugin. Can you build your project on 4.0? Give it a try and see what happens.
After talking to the company about their CRM setup, they explained there were two servers dedicated to running async plugins. It appears that Microsoft Dynamics CRM always runs the plugins on whatever server initiated the update. Normally, that would be the web servers because the update is initiated by IIS. However, in this case, that would be the async servers. I simply had to install .NET 4.5 on these two servers and the problem went away.
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 am required to create a simple application. Since I am good at WPF and I don't know win forms that good I implemented my application by creating a .Net Framework 4.0 WPF project in Visual Studio. Everything works great the application runs like it is supposed to.
Since the application is required to run in multiple platforms (Windows XP and above) I am including the prerequisites when publishing my applications. The prerequisites happen to be:
1) WIC (Windows Imaging Component) old computers need that to run the .net framework 4.0
2) Windows installer 3.1 (needed in order to install the next prerequisite)
3) Windows .NET Framework 4.0 Client Profile
If I install those prerequisites then the application runs like it is supposed to.
Now the problem is:
My boss did not approve my application because he tried installing it in a Windows XP machine with SP2 and this are the things that happened:
Step 1)
// first prerequisite (WIC) took less than 1 minute to install everything
// is working great so far.
Step 2)
// second prerequisite (Windows Installer 3.1) takes about 2 minutes to install
// which is great. After the installation is done the computer needs to be
// restarted in order to continue with the installation. Things are not going
// that good now but we are still ok...
Step 3)
// After the computer is done rebooting it continues with the last prerequisite
// (Windows .NET Framework 4.0 Client Profile). That takes 10 minutes to install!!!!
Step 4)
// My application has all the prerequisites needed to be installed so it installs in
// about 1 minute
We recorded the time, and the application took about 25 minutes to install from start to finish. The computer where we tested the installation was a virtual computer using 2 cores and 1 GB of memory with 3.1 GHZ.
What do you guys recommend in order to speed up this installation? Should I use a different technology such as windows forms using .net 2.0? It will be nice if I can deploy the application that I have already created. If you guys could help me make this application portable I will really appreciate it. In order to do so I tried building my application with all the required references copied to the output directory. That did not work... Or any ideas of how to make the installation be faster will be of great help as well.
If you're using .NET Framework 4.0 (which is not going to come out-of-the-box with any versions of Windows, especially Windows XP) there's no way to get around the install of .NET 4.0 on the target machine. Your major bottleneck is going to be the download of .NET 4.0 files from Microsoft to the machine.
I've run into similar problems where the initial install of an application takes forever because of the .NET 4.0 download and install. We even encountered an issue where the application couldn't be install because there was insufficient disk space for the download.
One option would be to pre-push the prereqs out to all the machines you'll be install this on before deploying your application.
Otherwise, you might be forced to use an older version of the .NET framework. Here's a list of the framework versions which shipped with various versions of windows.
http://blogs.msdn.com/b/astebner/archive/2007/03/14/mailbag-what-version-of-the-net-framework-is-included-in-what-version-of-the-os.aspx
Unfortunately, if your organization is committed to using a 10 year old operating system then they either need to accept that modern tools will require a lengthy install process while all prereqs are loaded... or else force you to use a 10 year old software technolgy.
We are using JBoss 4.2 GA, and need use a newest version in some new project.
I heard that JBoss 5.0 encounter such bugs... is this correct?
If not, which exact version of 5.0 to use?? and what about 6.0??
Thanks.
JBoss AS 5.1 is perfectly fine. Every app server has bugs, they're big, complex applications in themselves, but 5.1 is solid.
JBoss AS 6 hasn't been released yet, it's still in beta.
Jboss Application Server 7 is released, and up to a beta version of 7.1.0. You can download a copy here, and find the Getting Started Guides here.
As with any major revision of an application server, there are significant changes that might impact upon your business and will need to be considered in the context of your use case. Being an open source project, the early praise and early bugs are in the public arena, so it is easy to research for yourself.
Working on a documentation project involving AS7 I have seen some of the great work that the team has undertaken, and I couldn't imagine going back to a previous version now I've enjoyed the fast boot-up times, the ease of application deployment, custom configuration and the powerful Management CLI.
These kinds of improvements and features, not just constrained to JBoss Application Server or JBoss Enterprize Application Platform, speak volumes about the speed, stability and usability that will be increasing exponentially in this field for all competitors over the coming years. I'd urge you to check out the current generation of application servers if your experience is largely with JBoss AS 4.2.
All,
I'm currently in the process of attempting to create a repeatable process for the upgrade of a TFS 2008 installation to new hardware in what Microsoft call a migration upgrade, but am experiencing issues when building the VS 2008 projects on the new hardware.
Our TFS 2008 installation consists of two machines; one which houses the SQL databases and Application Tier, and the other which acts as a dedicated Build Server.
The new hardware for our TFS 2010 installation consists of two machines; one which houses the SQL databases, Application Tier, SharePoint and the Reporting Services.
So far, I have managed to successfully repeat the backup of the necessary TFS databases from the original server to the new server and restore them, followed by the 'tfsconfig import' command to successfully import and upgrade the databases to a Team Project Collection. The Team Project Collection appears correctly, and it is immediately usable. All security settings, shelvesets, workspaces etc. are intact.
Our issues start when we begin trying to build solutions. We are initially trying to build these solutions without upgrading them to the VS 2010 format, nor modifying the target Framework of any of the projects.
We get the following errors when various projects build:
< filename>.resx(x,y): error RG0000: Could not find a type for a name. The type name was 'System.Collections.Generic.List`1[[< class>, < assemnbly>, Version=a.b.c.d, Culture=neutral, PublicKeyToken=9557797252b44220]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Line x, position y. [< projectfilename>]
ResGen : error RG0000: Could not load referenced assembly "< filename>.dll". Caught a FileNotFoundException saying "Could not load file or assembly '< filename>.dll' or one of its dependencies. The system cannot find the file specified.". [< projectfilename>]
Various 'ambiguous' MSBuild target references when compiling workflow-related projects:
C:\Program Files (x86)\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.Targets (153): 'GeneratedCodeAttribute' is ambiguous in the namespace 'System.CodeDom.Compiler'.
There are various suggestions about how to eliminate these issues, including modifying the 32-bit support flag on ResGen, or forcing the use of the 64-bit ResGen, and upgrading projects to VS 2010 format and changing them to target Framework 4.
Issue 1. can be fixed by changing the offending projects to target Framework 4, however this particular project cannot be upgraded yet due to compatibility issues, and I have not yet found a solution for issues 2. & 3.
We have upwards of 20 Team Projects, with multiple branches in each, and would therefore (due to the amount of work involved) like to avoid manually changing all projects/solutions (especially as some products cannot be upgraded to Framework 4 yet for compatibility reasons, and building Framework 3.5 targeted projects in Framework 4 MSBuild does not appear to be as compatible as Microsoft would have us believe).
If anybody has any ideas which may prove helpful, then please let me know.
Cheers,
Antony
EDIT:
Issue 1 has been seen by other people, and relates to resource files referencing generic lists of a custom type. As it turns out, these were superfluous in our project, so I simply removed them, and that build issue was history.
Issue 2 seems to have dissappeared all by itself, possibly as a result of fixing issue 1.
Issue 3 relates to building VS2008 Workflow projects in MSBuild 4, when they target Framework 3.5. Microsoft, in their infinite wisdom, have apparently chosen to not address this issue (Link to Connect site), and there are several ideas to fix it (referencing specific versions of the Framework, changing the build workflow to use MSBuild 3.5), none of which work.
So our upgrade to 2010 is on hold it would seem, until either the products for which we build the 3.5 workflows (CRM 4.0 and SharePoint 2007/2010) support Framework 4, or until Microsoft fix the issue.
EDIT:
Microsoft have admitted that there is an issue, and have released the following information relating to the above KB number: http://support.microsoft.com/kb/2023579
As stated in my commented addition on my original post, this issue relating to the workflows not building is indeed resolved by a patch for the Microsot .Net Framework 4 Extended, which is outlined in KB2023579, which has not yet been made public (at the time of this post).
This solution was provided by Microsoft through a support call, and as such I am bound by the terms and conditions of that call, which prevent me from distributing a link to the patch until the official KB article is made available, at which point I will post the link. Sorry.
Hotfix that worked for us: http://support.microsoft.com/kb/2249629