I finally got nMap working under Vista. I don't know if it was the latest version of nMap I installed (4.23RC3) or winPCap (4.02), or some other change to Vista (update). You do need to run it as an administrator to get access to the network card at the low level required by the tool. I don't know when they added this, but in the 4.23RC3 the GUI is included and works well. The command line is still there in the background available for the power users. One nice thing about the GUI is that as you make changes, you see the command line that is going to be execute.
In a recent email from MSDN Flash, I first learned of the new Parallel Extensions to the .Net Framework 3.5. This is an out of band release that is currently available as a CTP on Microsoft Downloads. The description in the MSDN Flash newsletter has me pretty excited about what this offers. [Parallel Extensions] is a managed programming model for data parallelism, task parallelism, and coordination on parallel hardware unified by a common work scheduler. ... Parallel Extensions provides library-based support for introducing concurrency into applications written in with any .NET language, including but not limited to C# and Visual Basic. It is specifically designed to take advantage of multi-core processors (among other things), which is important due to the recent (last 2 years) shift in the industry from raw clock speed to multi-core. The computational power of multi-core processors, new programming models and platforms, and advanced research in usability all promise to change the way people interact with computers. While excited, I do have some reservations. Encapsulating the lower level knowledge needed to take advantage of multiple cores will speed up development, but it will reduce the number of programmers who know how that lower level stuff needs to be written. The concepts used to take advantage of multi-cores, should be very similar to those required to take advantage of multi-threading, which is more "widely available" on the compact framework (although I am seeing more and more embedded computers with Core 2 Duo's). If this framework is only available for the full framework, the pool of skilled workers available for the compact framework could diminish (even more so). I actually have more of a need to take advantage of multi-threading, and parallel processing in compact framework applications. As far as asp.net applications, I would like to see if this is something that would be recommended for them. Long running processes that would take advantage of this new framework, are usually best left outside the asp.net application. Speaking of long running processes, that is the 3rd area I work in, and in a traditional environment, would love to take advantage of this. However, the applications I am writing are all running on VMWare ESX, and IT has it set so that each VM only has a single CPU, and puts the burden of scheduling the 8 physical cores on ESX itself. This will probably end up being something I try to work into personal projects. Unfortunately, I do not have the time to play with the CTP at this moment, but it is something I defiantly want to look into in the future. Additional Information:
From Dave Northey's blog, comes a link to an Active Directory tool previously only available to MS Premier Support. The tool discovers information about your Active Directory and Exchange infrastructure and exports it to Visio. The tool is available free of charge from Microsoft downloads.
Avoiding Development Disasters is the tile of an article I came across today and talks about how and why software projects fail. Here's what I got out of the article. FBI Virtual Case File The article opens up talking about the monumental failure that is/was the VCF and touches 6 factors which lead to the projects failure. - Lack of an Enterprise Architecture - Unfortunately the article doesn't go into what they did have, have not.
- Poor management of developers, including a lack of management or micro-management
- Unqualified persons were placed in critical roles
- Constantly changing requirements
- Scope Creep
- Throwing more developers at the project in a last ditch effort to meet deadlines.
I am personally experiencing 3 of the listed items on a current development project, although it's far from a $100 million dollar system, I bet there are some striking similarities. I would imagine that every project at every company experiences 1 or more of the things in that list to some extent or another. What is Success? The VCF was eventually scrapped, but the author claims, that had it gone to production, it would have been deemed a success, even with all it's flaws. The author goes on to say that this is the general practice in the software industry (at least enterprise applications). As much as I like Microsoft, I think Vista is a shining example of this (although perhaps it is deemed less of a success inside of Microsoft). I have to agree, and would be willing to say it's common in software projects in general, from small to large. How many times is a game released, and the day of, a patch is released? Even Epic Games, creators of the Unreal platform, and who coined the phrase "When it's done", still manage to release a product with known issues. I'm not trying to criticize any one company or developer, other then myself, as I have created some less then magnificent code over my short life as a developer. I think part of the problem is that there are no points for creating good code. At the end of the day, "Well it works doesn't it?" pays the bills. Why is it so hard to write code, almost 30-40 years since the first programs were written? We have better tools, faster computers, and years of other people's failures to learn from, and here we are, still producing less then our potential. The Code to Ruin The diagram "The Code to Ruin" presented in the article is so true, it's scary. You pretty much know what's going to happen before you start the project, but you still can't avoid it. That's depressing at best. Maintainability The article spends the last half, talking about the maintainability of code. Without code that is maintainable, while you launch may be a success, you next point release is probably going to be a failure. The article states that enterprise software should have a 15 year life span, that's longer then I have been coding. I think ideas such as software as a service might help us reach that goal, and have more maintainable code overall. I'm not taking about providing software as a service, I mean, that the internal make up of your application is constructed from (loosely coupled) services. Breaking stuff down into more manageable pieces seems to be the way to go. We already do it with proper OOD design, we should also be applying it to the system in general. Of course there is a trade off, the most notable to me being one of performance, but that's what these faster computers are for ;) All in all, it was a good article, and made me really think about software projects, both past and current that I am working on. I have to imagine that there are people out there that would be the perfect compliment to a talented programmer such as myself (well at least I think I'm talented). Or, does it mean, that I need to spend less time with technology and programming, and learn more skills like project management, documentation, business analysis, etc.? To specialize, or generalize, that is the question?
Sometimes a file gets locked in TFS, and for whatever reason, you need to unlock it. You can use the tf command line utility to accomplish this. tf lock /lock:none $/Project/AnyFile.extension /workspace:ComputerName;User /s:http://TfsServer.Com:8080
Server Today I tackled upgrading my development server from BizTalk 2006 (Developer Edition) to R2 (Developer Edition). You can read my previous post on installing R2 on a clean machine. Detailed instructions (for all supported install scenarios) can be downloaded from Microsoft Downloads (See below for another link). Upgrading was extremely easy, and I encountered no errors or warnings. I used the same cab file I downloaded for my clean install, since it was the same platform (Windows Server 2003 32 bit). You need to stop all BizTalk related services, and IIS (this is detailed in the instructions) during the install, and then restart them after the upgrade is finished. There wasn't even a reboot required. One thing I'd like to point out, is that upon first glance, it looks like you are still running BizTalk 2006. The banner in the admin console doesn't mention R2, there is no new group in start/programs, even though the upgrade process lists an unistall step of BizTalk 2006 and an install of R2, there is no R2 program listed in Add/Remove programs, and the 2006 is still listed. Re-Running the R2 installer gives you options to repair, modify or remove, so the installer seems to think everything is correctly installed. Not quite convinced I decided to look into this further. There is a registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\, which lists versions. I had a sub key for 3.0 and 3.5_Migrated. On my clean install, there is no 3.5_Mirgrated key, the admin console, and Add/Remove programs all list 2006 (not R2), so I guess that's just the way it is. If you are in the admin console and go to Help\About Microsoft BizTalk Server Administration, it lists version 3.6.1404 (compared to version 3.5.1602 before the upgrade). I guess I had an expectation that it would say R2 somewhere. Another gotcha, is that the new WCF adapters are not installed by default. After the upgrade process, you have to re-run the installer and choose modify. Then you can add the WCF adapters, both under the BizTalk runtime, and admin tool. That goes for any optional component. If it wasn't installed before the upgrade, you have to go in and add it after the fact. Workstation Figured now was as good as time as ever to upgrade my workstation (development components) as well. The link I posted above didn't have a guide for installing on Vista, but a quick search found another page on Microsoft Downloads that did have a Vista Guide. I wasn't planning on reading the guide, but I couldn't get the install process to even start under Vista, so figured some trickery might be involved. The first thing I did was find the redistributable components for Vista, so I could start downloading those while reading the install guide. The link to the components in including in the Technical Appendix in the install guide, and at the time of this post, the direct link is: http://go.microsoft.com/fwlink/?LinkId=81432, and weigh in around 30MB. Since I just want the development tools, I skipped to page 21 in the guide, which are where the install instructions start. There was no special steps listed for Vista. I ended up rebooting my computer, and still couldn't get it to start (clicking install BizTalk from the setup screen didn't seem to kick off the msi process). I tried running the msi directly, and got the expected error saying to run setup. So I went back to setup, and this time it worked, weird. After I actually got the installer running, everything after that was as easy as the server upgrade. I could have appreciated support for VS 2008, but 2005 isn't all that bad. The only time I would notice a difference is if I am working on a class library instead of a BizTalk artifact.
Rant I don't like anti-virus software, and I like real time virus scanning even more. It's like trying to fix a paper cut with brain surgery. There are plenty of guidelines out there for how you can configure your computer, and how you can be a smarter user and avoid virus, spyware etc. Those are mainly for workstations and home PCs, but what about servers? My take on servers is, you shouldn't be doing anything that compromises the security of a server, and that includes browsing the web, using a standard or admin account. So if you cut out browsing, don't install warez, what's left? I know, I know, what about things like Code Red? When Code Red first hit, it didn't matter if you anti-virus installed or not, the attack was so new that your only defense was to pull your web server off line until you got it patched. A virus from last year, should never find it's way onto your server if you are careful, leaving zero-day exploits and black market hacks, that AV isn't going to catch it right away anyway. About the only thing AV software is good for, is finding that bot net Trojan your Mom gets when she installs Super Happy Smiley emoticons for email. I know I'm not going to win the argument for not having any anti-virus installed, but let's at least be intelligent about it ok? If you call yourself an IT administrator, Network Administrator, etc, now is the time to earn that title. Anyone can carpet bomb a network with an enterprise anti-virus package. The AV makers even make it easy to auto deploy their poorly written, resource hogging craplets via auto install software and group policy. A true administrator will take the time to come up with a comprehensive approach to computer and network defense, including the intelligent installation and configuration of AV software. I found an excellent document on folders and files you should seriously consider exempting from real time, and even on demand scans. Yeah, yeah, I know, just run Linux on the desktop and use a LAMP stack for your servers.
My task (well one of them) for the week was to update one of our Custom BizTalk adapters. Be sure to read my post on how to Install a custom BizTalk Adapter for some background information. One of the changes I needed to make (which I had been putting off), was changing the namespace. Namespaces are case sensitive in the world of BizTalk. So if you change the namespace, you have to update the registry entry for the adapter with the new case sensitive namespace. Also, it seems like you need to uninstall the adapter from BizTalk in order to use the new assembly, since the TypeName changed. In order to do this, I used the BizTalk admin tool to delete the adapter (BizTalk Group\Platform Settings\Adapters), update the registry, then re-add the adapter. If you are making calls to resource files where you are specifying the type name, be sure to update the string you are passing in as those calls will now fail. Even better, you should have a single string constant that defines the type name so you only have to make this change once. Once the namespace change was finished, further changes to the assembly, only required me to copy over the existing assembly and restart the host process. Exceptions in adapters, at least our custom adapter, would cause the host process to keep restarting, so I ended up disabling the windows service for the host process after restarting/starting it, just to keep down on the repetitive errors. Robust and proper error handling is a must in custom BizTalk artifacts. I find that writing errors to the event log works the best, and to include a domain specific error message, error code, and Exception.ToString(). The error codes are nice because you can go back in search for them in the code. They also are easily referenced in tech support and trouble shooting documentation. In my specific case, a custom adapter which used the BizTalk PollTask mechanism, uncaught exceptions are written to the event log with the full stack trace. This means, that you don't need to catch general exceptions (and static code analysis says we shouldn't). Starting from exceptions thrown by PollTask, I added specific catch blocks to log specific information useful for trouble shooting, and re-threw the exception using "throw;" which re-throws the original exception. This causes the adapter to error out, and to be honest I do not know if this is the best way to handle things. It results in the host process restarting as mentioned above. When the out of the box adapters have errors, like the File adapter not having permissions to the specified folder, the adapter is eventually shut down.
Found some more information on TFS 2008 RTM from bharry's blog on MSDN. Most important to me and my team, is that the RTM media is not available for volume license customers until sometime in January. However, you could upgrade to the RTM Trial, and then add in your PID (Product ID) in January when it's finally available. The trial is good for 90 days, and bharry assures his readers that PID's for volume license customers will be available before then, and if not to contact him directly. Upgrading to RTM sounds like something I will probably do around Christmas, as it's usually a slow week anyway. This would give me until the end of March to get my PID, which is probably close to when the beta we are currently running would be expiring anyway. Speaking of upgrading, it sounds like the process outlined by ScottGu which I talk about in my previous post, also apply to TFS. There is a link script on bharry's post, which is supposed to help with the process. I will try to use the script for when I update my primary workstation, and will report back on how well it works.
Note: While I didn't have any problems, I would recommend keeping the iso for Beta 2 around until you are confident you got everything removed. Sometimes software needs to get something from the original installer to uninstall. In case you have been living under a rock this week, VS 2008 RTM was released. I don't expect to see much difference between Beta 2 and RTM, given how solid of a product Beta 2 was. ScottGu has a post on the recommended steps to uninstall Beta2 and install the RTM version. It sounds like you could install on the top of Beta 2, but I prefer to put forth the extra effort to get a "clean" install, or at least as clean as I can get without wiping my machine (is this another example of where moving to virtual platform would make sense?). Of course the first step was to obtain VS 2008 Team Suite from MSDN, which was a bit of a challenge earlier in the week. I'm assuming everyone was trying to get their hands on it, and unless Microsoft is cheap when it comes to bandwidth (doubtful), it goes to show how much people wanted this as soon as it was released. ScottGu had a previous post about where to get all the bits (including the 3.5 redistributable), and I found this post which led me to the stand alone download for Team Explorer. Next, I followed the recommended uninstall order. I'm glad that I don't install things I know I will never use, less things to uninstall. The names provided in Scott's post are word for word as they show up in Add/Remove programs, so feel free to sort by name. Even with detailed instructions, I still managed to screw up. .Net Framework 3.5 looks very similar to .Net Compact Framework 3.5, and I ended up uninstalling the full framework first. Not on the list, is Team Explorer, and Visual Studio itself. I opted to uninstall Team Explorer first, and the process froze on me. A "quick" reboot seemed to fix the problem. I proceeded with uninstalling Team Explorer, and the two entries for Visual Studio. I also rebooted again as per Scott's recommendation, and then began the install process, starting with Team Suite, and then Team Explorer and a few more reboots and I was done. Update: I came across a script which is supposed to help with the uninstall of the Beta Bits.
|