We've got some ancient of days COM+ components that we wrote long ago, that we're trying to migrate onto a VM. Currently they're running on a Windows 2003 R2 server, working fine. But they're not working on a 2008 R2 server that the VM is. It appears as though we just can't "reach" them at all from the VB6 apps on the client machine. Now sure how to proceed from this point forward. Any ideas, as to how to diagnose this problem would be helpful, please.
You're not giving us very much information to go on.
You might be interested in these links:
.Net COM+ Interop Part I
Debugging COM+ Applications Part II
Alternatively, you might find it easier to just install Windows 2000 as a standalone server on your VM, and run your application off of it.
Related
Hi I have a console app which I need to start up when Windows Server 2012 starts and without needing to login. I've done a bit of research and people advise a windows service is the correct approach, however the links are quite old and I wanted to confirm this is still the case, or indeed correct at all. Cheers.
Yes, Windows Service is still the most popular way to write and run servers and or a 'daemon' in Windows OS.
Depending on what your application is doing, you might have other options though, e.g. hosting an application in IIS (Microsoft's Web server application in Windows Server).
More recently, Microsoft has been working with Docker to also allow the use of containerized application deployments, which is available in new versions of Windows Server (Windows Server 2016).
Here are a few resources for more reading:
For .NET developers: Walkthrough: Creating a Windows Service Application in the Component Designer
Not just for .NET developers: Quick Start: Windows Containers on Windows Server
Ill need to set up a test IIS.
From a rapid research, ive found that Win7 and Server 2012r2 are pretty much offering the same (for IIS purposes).
Major difference is supported RAM and parallel RDP sessions.
Rather than that, relying on the fact i need IIS, which one is the right OS ?
Many thanks !
Not really the same at all. Windows 7 uses IIS 7, whereas Windows Server 2012, uses IIS 8. Plus, Windows 7/Windows 8 are consumer class OSes. They're not intended for running things like web servers. Likewise, Windows Server 2012 is kind of inappropriate as something like a development machine.
If you're talking about "test" in the sense of QA/staging server, then you should use an actual server class version of Windows. If you're talking about a machine to do development on, then you can stick with something like Windows 7 or 8, but then, you shouldn't even be worry about IIS. You'd just have Visual Studio and run everything through IIS Express.
We are moving to an all-64-bit development environment. Unfortunately VS 2008 and, more importantly, its built-in web server, run in 32-bit mode. When debugging code that references 64-bit assemblies - Oracle.DataAccess, for example - we experience the dreaded System.BadImageFormatException.
Can anyone offer any strategies for debugging code with 64-bit dependencies in VS? I suppose we could use a 32-bit Oracle provider, but we would like to emulate the production environment as closely as possible.
I have a similar setup on 64 bit Vista where I have the web site deployed in IIS - this site has in been successfully run and debugged in both 32 and 64 bit.
The biggest problem I have found is working in a mixed environment where some members on the project team are still on 32 bit Windows (both XP and Vista).
This causes headaches with project references to Oracle.DataAccess which I have only managed to solve with bindingRedirect entries in the web.config file in order to point to the correct version of the assembly.
If you use IIS7 you can choose 32/64 bit mode. You will then have to have your projects kick up with IIS instead of cassini which takes a little bit of work, but I think it will solve the problem with Oracle at least. Honestly I don't know how that would all work when attaching at 32bit debugger to it.
We use VMware hosts to give each of our web site developers their own virtual web server. You can use full IIS (as #KevinWon suggested) and install a 64-bit version of the debugger on them. I don't know the specifics of what our guys do - I found this out over a coffee the other day.
Set up an local IIS on your computer and set it to run in 32bit mode
http://kb.parallels.com/en/2131
If you enable the Debuging mode you can work with it, just like you would with the integrated development server. But you don't have to mess with the 32/64bit assemblies
Here is a question not directly related to programming.
Being fed up with Microsoft Windows XP Professional, and the lots of eye-candy, I want to try Microsoft Windows Server 2003 as the main OS on my development PC. (The other reason is a better version of IIS than 5.1). And knowing that Win2K3 was originally designed as a Server OS, I think that I should make it somehow more "workstation friendly".
My question is: How do I transform Win2K3 (Standard Edition most probably) into a Workstation OS? Any articles or links are highly appreciated.
PS: My development PC must run mainly MS Visual Studio 2008, MS SQL Server 2008, MS Expression Studio 2, different Oracle software (10gR2, ExpressEdition, 11g) and other little utilities (a testing framework, a subversion tool - TFS, a web browser, a bittorrent client, etc). All of this are compatible with Win2K3, as I previously checked.
Tnks
I only server OS as my workstation, I had Server 2003 before I switched to Server 2008. There's a guide you can find here http://www.msfn.org/win2k3/.
You shouldn't run into any problems. Most of windows xp drivers will work on server 2003, however, some apps won't. Especially those that check for the OS version before installing. But you shouldn't have any problems with VS2008, Expression and anything you posted.
For me the only thing that was troublesome was running iTunes on server 2003, it doesn't look as good.
And if you like the eye candy you can turn it on by starting the Theme service and changing a few settings.
You shouldn't run into any issues running those applications on Server 2003.
The last time I personally ran 2003 on a workstation the only real big change was changing the security settings of internet explorer.
If you run one of the free anti-virus software packages you may find that they will not install on a Server OS.
edit: As another poster has suggested I would also go straight to server 2008 if it is an options. Server 2008 runs very well as a workstation OS and if you're hardware supports it the virtual server works very well.
Here's links for turning 2003 into workstation:
http://www.google.com/search?hl=en&q=windows+server+2003+workstation+converter
If you'd like use Windows Server 2008 as a workstation, runs much better (faster) than a regular Vista install:
http://www.google.com/search?hl=en&q=windows+server+2008+workstation+converter&aq=1&oq=windows+server+2008+work
or try getting your hands on Windows 7 RC1 which runs quite well.
None of the software types you've listed has any workstation-biased dependencies that I'm aware of. Expression Blend may suffer a bit depending on your hardware and drivers, as WPF is a little more demanding of visual goo than most other development tools for Windows forms.
What are the best practices in setting up a new instance of TFS 2008 Workgroup edition?
Specifically, the constraints are as follows:
Must install on an existing Windows Server 2008 64 bit
TFS application layer is 32 bit only
Should I install SQL Server 2008, Sharepoint and the app layer in a virtual instance of Windows Server 2008 or 2003(I am already running Hyper-V) or split the layers with a database on the host OS and the app layer in a virtual machine?
Edit: Apparently, splitting the layers is not recommended
This is my recipe for installing TFS 2008 SP1.
There is no domain controller in this scenario, we are only a couple of users. If I was to do it again, I would consider changing our environement to use a active directory domain.
Host Server running Windows Server 2008 with 8GB RAM and quad processor
Fresh install of Windows Server 2008 32bit in a VM under Hyper-V
Install Application Server role with IIS
Install SQL Server 2008 Standard edition
Use a user account for Reporting Services and Analysis Services
Create a slipstreamed image of TFS 2008 with SP1 and install TFS
Install VSTS 2008
Install Team System Explorer
Install VSTS 2008 SP1
Install TFS Web Access Power tool
After installing everything, reports were not generated. Found this forum post that helped resolve the problem.
Open p://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx
Run the webservice (see above link for details), it will take a little while, the tfsWarehouse will be rebuilt
It is very important to do things in order, download the installation guide and follow it to the letter. I forgot to install the Team System Explorer until after installing SP1 and ventured into all sorts of problems. Installing SP1 once more fixed that.
One critical thing you has to keep in mind about TFS, is that it likes to have the machine all to it self. So if you have to create a separate instance on Hyper-V do it using the proven Windows Server 2003 platform with SQL Server 2005.
I am sure Microsoft has done a great job getting it to work under Windows Server 2008 and SQL Server 2008, however you don't get any additional features with this newer install and it is currently unproven in the wild.
So my recommendation is to stick with what is known until the next release of TFS comes out.
Also splitting the layers is definitely not recommended, especially in the workgroup edition where you will only be allowed to have 5 licensed users. Those 5 users will never exceed the server's needs. Also my recommendation is to not update Sharepoint if you don't need to. In my environment, we don't really use Sharepoint all that much, so I left it alone. Sharepoint is usually, in my experience, where most of the problems come from with TFS.
I just upgraded our team to TFS 2008, from TFS 2005. The hardest part was upgrading SharePoint 2.0 to 3.0, so I would make sure to do that first, if you have not already installed TFS 2008. We had a couple of other difficulties, but they were all either related to the SharePoint upgrade, or to the fact that we were using an aftermarket Policy package - Scrum for TeamSystem. We are on SQL Server 2005, so I cannot address SQL Server 2008. As for splitting the layers, we did not do this either, as we are running on Windows Server 2003 and everything ran under the host OS.
Splitting the layers is only needed for more than 450 users.
I would also recommend having the Build Server on a completely seperate machine. Building is very file system intensive. SQL Server performs best when it has complete control of a file system - so having build and TFS on the same machine may create performance issues while builds are executing.
Perhaps this can be alleviated with proper tuning and seperate physical drives - but I'd think in the long run it would be a lot simpler to just either use some old hardware - or spin up a small virtual machine on a seperate host for your builds