Finding out the .NET Framework version that an assembly uses

There will be cases where you would need to find out the .NET Framework version of an application or assembly running on a machine and you just don't have the right tools. This is especially true when you need to promote your code from test to production environment. If there is only one version of the .NET Framework on the machine, it would be easy. But if you have servers with multiple versions of the .NET Framework installed and the assembly is not configured to bind to the correct framework version, you might end up having an application that might break due to incompatibility issues. This is true for .NET Framework versions 2.0 and below although I haven't really tried out the newer ones but it would be basically the same since .NET Framework 3.0 and 3.5 are just stacks on top of 2.0

If you don't have the tools on the server to check, you can simply copy the assembly on your local machine and use either ILDASM.exe or simply download RedGate's Reflector. Reflector does not need installation as long as you have the appropriate .NET Framework versions in your machine. Just extract the EXE and CONFIG files and you're good to go. A video demonstrating how to use RedGate's Reflector can be found here

Transfering Windows Scheduled Task Jobs between servers

There might be some cases where you need to transfer Windows Scheduled Task jobs like maybe promoting them from test to production. The simplest way to do it is by simply opening the Windows Scheduled Task in Windows Explorer for the source and the destination servers (you can do this by expanding on My Network Places and selecting the destination server. Just remember to open separate window for the two of them). Copying and pasting between windows should do the trick. It would be a bit challenging if the source and target servers are not in the domain as you would need an account that has the appropriate privileges on both machines

Windows 7 on VMWare Workstation 6.5

I was at the Microsoft Canada Energize IT Windows 7 Installfest event in Ottawa and volunteered to assist with the attendees while they were doing the installation. While the supported installation options during the event were clean install, upgrade, dual boot or virtualization using Hyper-V, Virtual PC or Virtual Server, a few of those who came were asking if they can install it on VMWare. Now, I have been working with VMWare for years now and my take on this is if its a Microsoft operating system and it runs on the Microsoft Virtualization products, it will definitely run on VMWare. I was making suggestions about how to go about it and the caveats when working with VMWare, I have never seen Windows 7 yet. So what I did was to fire up my VMWare Workstation and started installing Windows 7, just so I can answer the questions knowing I had he experience of doing it rather than just saying "I know it will work." I used the ISO image provided by Microsoft and the installation went really fast. If you've installed Windows Vista or Windows Server 2008 before, the process is pretty similar. I guess I'm on my way to playing with the Windows 7 image just to get the hang of it. And one thing is for sure, it will work on VMWare - even with 512MB of RAM.

Changing a SQL Server 2000 login

WARNING: This is not a recommended approach. Use at your own risk

While SQL Server 2005 has the ALTER LOGIN statement to change the properties of a SQL Server login account, SQL Server 2000 does not have such a command. Unfortunately, there are cases where you need to simply rename the login due to a misspelled name or a change management policy. The proper way to do it in SQL Server 2000 is to create the new login, map the permissions and roles of the existing login that you wish to change to this new login and, then, drop the old login. I wouldn't want to go thru that if I only have to rename the login. The only simpler way to do it is to modify the system tables. As I've said, it is not recommended to modify the system tables and/or objects directly so bear in mind that doing this would be at your own risk. This would also require that you torn on allowing ad hoc updates to system tables and turning it off afterwards

sp_CONFIGURE 'ALLOW UPDATES', 1
GO
RECONFIGURE WITH OVERRIDE
GO

UPDATE db..sysusers
SET name='newLogin'
WHERE
name='oldLogin'

UPDATE master..sysxlogins
SET name='newLogin'
WHERE
name='oldLogin'

sp_CONFIGURE 'ALLOW UPDATES', 0
GO
RECONFIGURE WITH OVERRIDE
GO

A similar stored procedure is described here