I have handful of applications that use .net 1.1 framework. We are upgrading our server's to 2008r2 64 bit or maybe even 2012 64 bit. Our client side apps will run on citrix that will also be on a 2008r2 64 bit or 2012 64bit box.
Now, I'm I correct in thinking that if.net 1.1 isn't installed then applications will automatically use a higher version of the framework? So what problems are there with this strategy:- Try the 1.1 apps on the new servers. If there work then I can delay upgrading them.
No they won't run unless .NET 1.1 is installed. Applications can only use the framework they are compiled for. (They maybe able to be upgraded if source code is available)
.NET 1.1 is available for 2008 server not R2 or 2012 server so you will have to upgrade them.
See here though http://support.microsoft.com/kb/2489698 (indicates it may be possible)
See this for Server 2012 http://msdn.microsoft.com/en-us/library/hh925570%28v=vs.110%29.aspx
Related
I'd like to install MongoDB Community Edition on my computer, which has the 64-bit Windows 10 Home OS, but the system requirements say I need Windows Server 2008 to do it.
I don't think my computer has Windows Server 2008. Is there any way around this? For example, would it work for small-scale databases, or is it totally incompatible without Windows Server 2008?
If I absolutely can't use MongoDB, is there another non-relational database that would work with my system? (It would have to be free.)
I admit that the download site is a bit confusing.
But you can simply download the MSI and install it on your Windows 10 machine. A Windows Server version is not required for the community edition.
Disclaimer: I have it on a Pro (Windows 7 and 10, without Windows 2008 or any other server) edition, not on a Home edition, but I'm pretty sure that it will work in the local machine context)
We have a classic ASP application we just migrated from Windows 2008 R2 to Windows 2012 R2 Core.
Apparently Core versions of windows don't include cdosys or cdonts and thus our application can no longer send email.
Most of the advice I can find suggests using system.net.mail for sending email which of course is a .NET technology and we're using classic ASP.
We do have .NET on our system but I'm not sure if classic ASP could talk to a .NET page for sending email?
Besides using a 3rd party COM utility like Persits ASPEmail are there any native ways of working around this?
We do NOT want to convert the server core instance to the full version of windows. That's killing an ant with a bazooka. This is only impacting two places in our code and everything else works just fine on core.
Unfortunately, CDONTS was superseded by CDOSYS some time ago. When migrating from Windows Server 2008 to Windows Server 2012 I had this exact same issue, but managed to find a fix.
It involves taking a copy of the cdonts.dll file from the Windows Server 2008 Server and adding it to the Windows Server 2012 server then registering it with the relevant COM subsystem without any need to change code or install a 3rd Party library.
Hopefully the same method will work with Core but I haven't tested it.
Our product needs to be compatible with versions of windows including Server 2003 and XP.
We have code first entity framework projects with various migrations.
We are deploying these migrations to create or update a database using the "migrate.exe", file version 6.0.21211.0, supplied in entity framework 6.0.2 nuget package.
When using XP itself with visual studio 2010 or Windows 7 with visual studio 2013 to install the package every time we run "migrate.exe", on an xp or server 2003 machine, we are getting a "not a valid win32 application" exception.
Is there a good reason why "migrate.exe" will not run on windows xp and windows server 2003 other than the fact they are operating systems that nobody really wants to support any more?
I managed to resolve this issue by downloading the source code for 6.0.2 version of entity framework, un-signing it in properties, then building it through .net 4.0 and not 4.5 by changing the solution configurations to Release40.
Source code can be found here:
http://entityframework.codeplex.com/SourceControl/changeset/7648d33dfb53589d9c32b605c61758a5a6c0b80b
I found it quite difficult to locate it.
You probably don't have .NET Framework installed on the machines where it fails.
(As a side note I believe both XP and 2003 go out of support soon so you may want to upgrade your environment...)
XP isn't a supported OS for .NET 4.5. This is a known issue.
I read a few months back that the reason XP can't install 4.5 is because there are kernel API that 4.5 calls which don't exist on XP. I also read that it would be possible to inject your own implementation of the 'new' kernel calls to an XP machine - and 4.5 could run.
I can no longer find this information. Does anyone know more about this?
A second, but related, question is - how can I take upgraded .Net 4.0 libraries from a windows 7 machine (which had 4.5 installed) and inject them into an xp machine? I believe I read that the implemention files of 4.5 are actually the same as the 4.0 files, there are not two sets. And in fact, the two .net folders (4.0 and 4.5) are only the interfaces - which link back to these same files. If this is the case, then a manual injection of the 4.0 files would likely need the solution to my first question.
In short - does anyone have more information about hacking/manually upgraded .net for xp?
Our product uses the JBoss 4.0.4 as an application server. Currently we are supporting Windows Server 2003 and planning to support Windows Server 2008. We want to know that is JBoss 4.0.4 fully compatible with Windows Server 2008 (64 bit)?
Please respond if anybody installed and used JBoss with Windows 2008.
Thanks
Since JBoss is 100% pure Java you can have it working on any Operating System that supports Java. So I guess that the real question is more "does my JVM run correctly on Windows 2008". According to this guide, JBoss needs a JDK 1.5 and should run on a 32-bit or 64-bit JVM on a 64-bit Windows 2008 machine.