Software Development

How to add separators between buttons in Visual Studio toolbars

icelava — Thu, 04 Sep 2008 06:02:09 GMT

How is it that I forget the steps to accomplish such a simple task so frequently? Do I have a poor memory, or is Visual Studio's method for adding separators beween toolbar buttons just plain unintuitive? I blame Visual Studio.

Here are the steps to once and for all prevent me from forgetting

1. Open the Customize dialog box for toolbars.
2. select a button that is already present in the toolbar. The Modify Selection drop-down button should become enabled.
3. Its pop-up menu has a Begin a Group check item at the bottom; use that to insert a separator before the button.

Error 112 Unknown server tag 'asp:ScriptManager' 'asp:UpdatePanel' on Windows 7

icelava — Thu, 22 Dec 2011 10:56:07 GMT

Ah, the joys of running legacy code on a modern computing environment.

Roughly every three years we get laptop refreshes, which may sound just about right from hardware progression timelines. The natural and unavoidable side effect of that is operating system is clean again. Meaning, we lose all those years of custom software installations and configurations that made our development "work" previously. So this time round with a 8GB dual-core HyperThreading x64 Windows 7. I only loaded in Visual Studios 2008 and 2010; do we still care about 2005?

Now at this point I am trying to learn Web Client Software Factory 2010 (WCSF) as that is the web framework being implemented for a project I might stand to support. Does anybody out there actually use WCSF? Regardless, I want to know it, so I am not lost when I look at the outcome system. But understanding WCSF is not an easy task as it is a sophisticated (or complex depending on your view) conglomerate of frameworks and design patterns that can attack you from multiple angles. It is tough finding current practical materials on it so I fell back on pnpguidance.net for the first version tutorial and sample. I converted the solution in VS2008 and attempted to run the web site,

Error 112 Unknown server tag 'asp:ScriptManager'
Error 112 Unknown server tag 'asp:UpdatePanel'

Seriously? How can those controls be unknown???

If you look at any search result on this matter the issue appears to be a lack of the additional tag declaration for ASP.NET AJAX controls.

<pages>

</controls>

</pages>

But wait a minute, it is right there in web.config. Don't joke with me, ASP.NET!

The problem is, as hinted above, this is a Windows 7 system. It comes with .NET Framework 3.5 out of the box. And ASP.NET 3.5 already has the AJAX extensions assembly system.web.extensions built in; I was all happy with that and took it for granted. But this sample is an ASP.NET 2.0 app. ASP.NET 2.0 did not have AJAX extensions on release. Thus it was referencing an assembly version that did not exist in my computer.

So I scrambled to download the missing component in the puzzle - ASP.NET AJAX 1.0 - so that a "traditional" ASP.NET 2.0 app that had no reliance on 3.5 assemblies can continue to run.

Ah, the joys of running legacy code on a modern computing environment.

Cannot open IIS 7 applicationHost.config in 64-bit Windows with 32-bit text editor

icelava — Sat, 21 Feb 2009 08:34:29 GMT

Every once in awhile, the very act of deviating from the norm to use a *gasp* 64-bit operating system meets with heavenly punishment. So much so that the most rudimentary tasks of opening a text file in a text editor is met with disapproval. I have already encountered this a few times ever since I installed x64 Windows Vista onto my home's main workstation; trying to work with IIS 7.0's new array of configuration files were a hassle. They are right there happily living in Windows Explorer. Opening them with Notepad is all fine and dandy. Like any normal operation should. But Visual Studio 2005 or 2008, or other Notepad replacements for the matter, fail mightily in their attempts to open those config files sitting innocently at C:\windows\system32\inetsrv\config. They consistently report being unable to find those files. They are right there, dammit! Are you blind?

Except, they aren't as "innocent" as one may think they are.

The problem with x64 Windows is certain paths are designated as 64-bit paths, and a 32-bit process, like Visual Studio, is being redirected by Windows to the 32-bit path at C:\windows\SysWOW64 whenever C:\windows\system32 is referenced. The 32-bit process thinks it is looking at C:\windows\system32\inetsrv\config when it has been given C:\windows\SysWOW64\inetsrv\config; which indeed contain none of those configuration files we are after.

It sure sucked using Notepad to edit those files. I want all the sugary goodness of Visual Studio!

Luckily, Robert McMurray came along more than a year later to explain what needs to be done in order to "double trick" 32-bit processes back into the original config directory. To summarise the steps in case the knowledge is lost on the other side, open a 64-bit command prompt and execute the following commands

cd /d "%systemdrive%\windows\syswow64\inetsrv"

move config configx86

MKLINK /d Config "%systemdrive%\windows\system32\inetsrv\Config"

It should report symbolic link created for Config <<===>> C:\windows\system32\inetsrv\Config

This effectively renames the 32-bit config directory so a symbolic link of that name can take its place to redirect back to the 64-bit path which we are really interested in.

Perusing HUGE XML content with structure intact

icelava — Tue, 14 Mar 2006 07:50:15 GMT

In a recent bid to tune performance when it came to processing huge XML files that can size 90-200MB, I was extremely annoyed and distressed that the regular programs I use to view XML data structured to their schema (as opposed to viewing as plain text) were all simply unable to deal with such magnitude.

Internet Explorer, Visual Studio, FrontPage, Firefox, all sent the CPU hurtling like a fireball (literally, given the CPU heat) consuming as much RAM as they can to recreate the entire DOM. And that is even for a 700KB odd XML file. Even XMLspy chokes to death.

Sometimes, the most useful utilities are those with little hype and branding. Asking around, one of my global colleagues recommended firstobject XML editor. They are not lying when they claim "high performance"; this program wisely avoids the conventional XML DOM approach and efficiently recreates the structure without shooting the computer with tranquilizers.

Sweet.

Why do WSE 3.0 projects in x64 Windows Vista generate SoapHttpClientProtocol instead of WebServicesClientProtocol?

icelava — Thu, 15 Jan 2009 07:24:03 GMT

In effort to upgrade my certification to MCPD-EA status, I have been retrograding to older frameworks I never had the chance to work on in the past three years. That means putting down that shiny WCF book and dusting off the WSE 3.0 MSDN documentation.

One of the IDE-incorporated features for WSE - which was long present in Visual Studio .NET 2003 - is to get Visual Studio 2005 to generate service proxies based on the Microsoft.Web.Services3.WebServicesClientProtocol class when the project is WSE-enabled. This class provides the base for all the tasty WSE functionality. However, on my main workstation, I consistently witness Visual Studio generating the stock SoapHttpClientProtocol. Manually editting the inheritance to WebServicesClientProtocol is a mere ephemeral accomplishment, since every attempt to Update Web Reference would just result in Visual Studio running the regular wsdl.exe generator.

But it sure worked fine on a laptop I have. The only major difference is the laptop is x86 Windows Vista. My main desktop workstation is x64 Windows Vista. That cannot be the problem, correct? Why, of course it is.

Straight after the launch of .NET Framework 2.0, Microsoft was visibily eager to concentrate on WCF (and .NET Framework 3.0 overall). That was a time when very few developers were even close to hitting the 4GB limit to realise they had to move on to x64 operating systems. Even as of now there are still not enough developers making the switch into 64-bit territory. I can see just how "much" attention WSE 3.0 got from an x64 perspective. Casting nets across various communities yield practically zero experience on what's happening here. It certainly took long enough for me to alter my choices in words to finally dig out the truth.

The WSE 3.0 installer fails to alter Visual Studio 2005's config file C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.config with the following entry.

Plug that in, and Visual Studio wakes up from its trance to realise there is a better world out there.

Multiple app.config files for deploying to different environments

icelava — Fri, 09 May 2008 11:14:21 GMT

One of the many great strides the ASP.NET team has taken to improve web developers' experience with Visual Studio came in the manifestation of the Web Deployment Project. The most important feature, at least in my eyes, is configuration section replacement. Keeping settings meant for different environments having it all consolidated into the correct web.config just got a whole lot more efficient and less error prone. This should have been in VS .NET 2002 right at the beginning of time, but I was just overjoyed nonetheless to finally have an "official" tool for that.

The problem is, that only applies to web sites. We develop more than just web sites here; Windows Forms client applications, background Windows services, or just plain old command-line console programs. How are we going to continue coping with these types of projects? There are actually a variety of different (yet similar) ways development teams are practising out there. I am not too sure why the method I discovered has not been done and discussed by others before, so I thought I'd log it down first for others' benefit of reviewing and comparison with other methods.

Know your destination environments

First thing is to identify the target environments your project outputs need to be deployed at. In this scenario we are just going to take the regular Debug and Release configurations as those used by developers to build and test on their local workstations. In addition, we will just determine that there are two external environments needing deployment - SIT and UAT.

This calls for separate app.config files carrying appropriate settings for the respective SIT and UAT servers. We are not looking at section replacement or external source reference here. This method simply duplicates the entire app.config file and changes the settings that need to be different. As such we shall name these files SIT.config and UAT.config. Fastest way is simply to copy and paste app.config directly back into the project, and rename the files. They can then be editted for their destination environments accordingly. Maintaining the uniformity of their structure should not be a problem.

Next, the solution and output projects need to create new configuration choices with the exact same names as those given to the .config files.

As with the screen shot, I have created "SIT" and "UAT" configurations for a number of Windows service projects, as well as for the solution itself. Remember that the solution configuration is independent from projects, and one can mix and match as required. That is why in the screenshot you can see a further "SIT_deploy" configuration for the solution; the projects themselves do not have that, and continue to use their own "SIT" configuration.

In actuality, it is optional for the solution to have these configurations defined, but absolutely required for the projects. This will become apparent as we explore the backend mechanism that is helping us build our projects in the first place - MSBuild.

MSBuild

If you have not realised, .NET Framework 2.0 introduced MSBuild, a "brand new" build engine that can compile Visual Studio 2005 projects without Visual Studio itself. It resembles NAnt really closely, a favoured open-source build engine with the flexibility for highly customised build processes and sequences. The cool thing is 2005 project files are actually MSBuild files themselves, and learning to understand and edit their XML structure instead of relying on the visual Visual Studio properties interface will reap great power. I will not write anything further about MSBuild per se - that is too huge a topic for this post. You should refer to the MSDN site for a conceptual introduction to MSBuild and its features. What I want to achieve here is the steps to accomplish deploying the appropriate app.config file.

Right click on one of the output projects, and select the Unload Project option. This will bring the project "offline", and it can be right-clicked again to expose the Edit function. This allows opening the project file in XML mode.

Scroll all the way down. There should be two commented out MSBuild targets there. One of them is called AfterBuild. Uncomment the AfterBuild node and edit it to look like this

What this does is to executed the AfterBuild task only if the configuration is "SIT" or "UAT". What did I state previously about naming the files and configurations exactly? So after a build is complete, the regular app.config file would have been placed in the output directory, renamed as <projectname>.exe.config. We should delete that file, since it is inappropriate for the SIT or UAT server. The moniker of $(TargetDir)$(TargetFileName).config will readily locate this file in the Delete task, and remove it. After that, we have to take the appropriate .config file based on the current configuration and convert that to replace the recently-deleted $(TargetDir)$(TargetFileName).config file. That is where $(ProjectDir)$(Configuration).config comes in to locate the file sitting in our project directory, and copy it to the current output directory.

Once done, save and Reload the project. Attempt a build using the SIT or UAT configuration. The output should be similar to this sample pattern

------ Build started: Project: afterbuild, Configuration: UAT Any CPU ------
Build started 9/5/2008 18:07:53.
Target CoreResGen:
No resources are out of date with respect to their source files. Skipping resource generation.

Target _CopyAppConfigFile:
Skipping target "_CopyAppConfigFile" because all output files are up-to-date with respect to the input files.

Target CopyFilesToOutputDirectory:
afterbuild -> C:\Projects\experiments\afterbuild\bin\UAT\afterbuild.exe

Target AfterBuild:
Deleting file "C:\Projects\experiments\afterbuild\bin\UAT\afterbuild.exe.config".
Copying file from "C:\Projects\experiments\afterbuild\UAT.config" to "C:\Projects\experiments\afterbuild\bin\UAT\afterbuild.exe.config".

Inspect the new <projectname>.exe.config and see if it contains the settings defined in UAT.config or SIT.config. Of course the MSBuild target could be expanded further to carry out more elaborate activities, but the straightforward method should suffice for a great number of build needs.

Signs your colleague may not be a good developer #8

icelava — Wed, 01 Sep 2010 04:15:36 GMT

catch (Exception ex)
{
if (IsWrongPassword(ex))
return "INCORRECT_PASSWORD";

throw new Exception(ex.Message, ex);
}

It's such a pity that a person who wisely makes meaningful method names, does not know that an Exception object is rethrowable.

Getting NDepend to cope with too many DataSet assemblies

icelava — Wed, 28 Apr 2010 09:23:06 GMT

Previously I was all happy and impressed by the performance and stability of NDepend v3.0. I still am, but alas, the fact remains that no matter how well you design and build something, there will always be something much more horrid to make your work crumble to pieces. When I started moving onto the larger deployments in the enterprise - numbering near 2000 assemblies - the several hundred DataSet assemblies reared their ugly heads again and utterly crushed NDepend with the weight of all their fatty members. This is no fault of NDepend, really, but just one of many signs that the architects who envisioned such work need to be burnt at the stake. With aircraft-grade jet fuel.

So how should one deal with when being faced with such gigantic .NET solutions? The most apparent workaround is simply to point out the DataSet assemblies and exclude them completely from analysis. But this prevents NDepend from gaining awareness of elements in those assemblies; crucial CQL queries regarding how DataSets and DataTables are being utilised cannot be fully realised.

Thankfully, there is an alternative - make the DataSet assemblies tier assemblies (blue) instead of application-level assemblies. How to do that? I discovered this by accident, when i originally moved all DataSet assemblies to a separate sub-directory. I did so to avoid selecting them with a Select-all operation during the assembly-selection process for Analysis. Of course, this only ended up with the above situation since my original intention was to exlcude the DataSet assemblies totally. The trick came when I actually re-added them into the (application) assembly list for analysis, and subsequently removed them. NDepend, knowing that those assemblies were being referenced and made use of, shifted their entries from the application column over to the tier column.

With such a setup, analysis of ~1500 application assemblies with ~300 tier DataSet assemblies was possible without OutOfMemoryException blowing up. With this manner of analysis completed, I was able to query out names of DataSets/DataTables being used within stacks of method calls, satisfying most of our data-related questions about our code base. Hopefully this tactic can help others faced with monolithtic systems manage a little better when attempting to do some untangling study with NDepend.

Visual Studio 2010 add-ons to make life easier

icelava — Tue, 08 Jun 2010 14:12:36 GMT

Now that .NET 4.0 and Visual Studio 2010 are in full swing, I think it's wise to open a page to jot down the useful add-ons that can enhance the developer experience. As time goes by, this list will get updated.

Windows Automation API 3.0

"Visual Studio 2010 runs faster when the Windows Automation API 3.0 is installed ..... Applications that use Windows Automation APIs can significantly decrease Microsoft Visual Studio IntelliSense performance if Windows Automation API 3.0 is not installed. For example, the Windows pen and touch services can significantly decrease Visual Studio IntelliSense performance if Windows Automation API 3.0 is not installed."

Visual Studio 2010 Productivity Power Tools

"A set of extensions to Visual Studio Professional (and above) which improves developer productivity."

How to tell what CPU platform .NET assemblies target

icelava — Mon, 15 Mar 2010 09:39:45 GMT

I had previously ranted about the lack of information and education concerning the 32-bit-to-64-bit development transition, and to this day still seems to remain a significant worry from what I observe of the developer community. In recent activity to look up 64-bit development issues, I came across Arthur C Clarke's blog entry which explains some "initimate" details about .NET assemblies.

http://chillicode.wordpress.com/2009/10/26/moving-asp-net-web-application-from-32-bit-to-64-bit/

Thought I'd just add this to my collection of notes. Worth a read.

Uninstall .NET Framework 4.0 Beta 1 - the self-mutilating way

icelava — Wed, 10 Feb 2010 18:50:47 GMT

I know I'm late to the game, but the virtual machine that was running my copy of .NET Framework 4.0 Beta 1 was "locked down" for several months because my previous hosting laptop got brutalised by Dell technicians last year. It was only recently did I manage to revive the virtual machine to carry out a complete uninstall of Beta 1 to make way for the younger, slimmer, sexier sister of Beta 2. But like any jealous sister, it was made clear to me that attempts to get rid of Beta 1 were just gonna be extremely difficult tasks:

Microsoft Common Language Runtime native compiler has stopped working

What???

In reading around pages of dicussions from developers experiencing similar pains in their to ditching Beta 1, it appeared I committed great sin in the eyes of the bible of pre-release software procedures - I picked what to uninstall first by my own unwise uneducated judgement. Silly me forgot the track record of past .NET Framework betas having extremely horrid uninstall experiences; there is a particular order in which the various software packages must be uninstalled.

So I got screwed big time. Not only couldn't I remove, neither could I repair the installation like others suggested as the solution.

Repair did not succeed. Fatal error during installation.

Thankfully, I found a discussion at Microsoft Connect that details what's the problem in my case: I uninstalled Microsoft Visual C++ 2010 Beta 1 x86 Runtime 10.0.20506 before uninstalling .NET Framework 4.0 itself. .NET Framework relies on this package to provide lower-level functionality. This has to be reinstalled using the following method (launching the .msi alone is not effective):

Navigate to <VS2010 beta 1 DVD drive>:\WCU\VCRuntimes\x86

Key in msiexec /i vc_runtime_x86.msi ADDEPLOY=1

This will allow the separate installtion of the C++ runtime binaries, and allow .NET Framework installation to carry out the Remove process.

Adios! And good riddance.

How to tell if your bank is up to date with their web development

icelava — Thu, 29 Oct 2009 03:45:34 GMT

Welcome to Q4 2009! Forget about Web 2.0, AJAX, and whatever dynamic browser interaction fluff other fancy sites offer. We are serious about backward browser compatibility here!

Signs your colleague may not be a good developer #7

icelava — Tue, 15 Sep 2009 08:39:27 GMT

Entire logic and workflow of the program takes place within the constructor of a class.

Job done upon instantiation! Now who does not want that?

Signs your colleague may not be a good developer #6

icelava — Mon, 14 Sep 2009 08:08:09 GMT

Highly adept at using code Regions, totally forgotten how to use different classes and methods/functions.

Enough said.

Directory Service is busy : Active Directory may not always provide the appropriate error message

icelava — Wed, 08 Apr 2009 04:21:00 GMT

In the past month, I have been helping out our customer look into some troubles their user account provisioning jobs have been encountering. One particular job is to take employee data files generated from their SAP system and determine the changes and provisioning the Active Directory domain accordingly. (i.e. update particulars, move OUs, set expiry dates, etc). This job of late has been terminated abruptly every morning as it crosses its five-hour execution limit, meaning it has not successfully completed its run. Catastrophic for the account administrators, as they have to provision user accounts manually upon user complaints.

This account provisioning module is a custom .NET program developed back in 2004 (In other words, .NET Framework 1.1). And naturally, makes use of the System.DirectoryServices namespace. From the error logs, we observed this slow processing was due to repeated "Directory Service is busy" errors that blow up when attempting to update a user's properties.

    “The Directory service is Busy”
   at System.DirectoryServices.Interop.IAds.SetInfo()
   at System.DirectoryServices.DirectoryEntry.CommitChanges()

When I was originally just given this error message alone by my colleage, I searched around the Internet and was rather surprised at just how little information there is regarding this situation. I was equally dismayed when nobody could offer any accurate insight on AD or Directory Services communities. Fearful that we won't be able to quickly determine the actual cause of the errors and be entrenched in the problem for a long time, I did a fundamental thing - asked for a copy of the error log file. With the full details at hand, I began to observe vital information:

The "Directory service is busy" error always happens at the same line of code. (CommitChanges())
The block of logic before CommitChanges() deals with unassigning the Manager property of a user, if it is found that a user has no supervisor.
Matching up with the SAP employee data file, users who are throwing those errors are users with no supervisors.
Each "Directory service is busy" error occurred around half a minute apart from each other, which suggested why the whole job took so long to run.

The code written to "unassign" a user's manager goes like

updateUser.Properties["manager"].Value = " ";

When I tested such a pattern on my home domain, it threw up the exact "Directory service is busy" error, after a similar half-minute delay. Interesting. On further study of this particular property, it turns out that an AD user's Manager has to be defined in the format of a Distinguished Name (DN). It has to point to another valid user object in the AD store. Giving a single " " space value probably sends the domain controller into a confused state looking for "void" before it gives up thinking it is simply too busy to find the real location. You know, like using a mirror to look into another mirror ad infinitum.

Why doesn't the domain controller return an immediate "Invalid DN for Manager" error message is beyond me.

By adjusting the code to be more respectful of AD conventions, I managed to eliminate the error.

if (updateUser.Properties.Contains("manager"))
updateUser.Properties["manager"].RemoveAt(0);

But then everybody would probably be asking, did the previous developers even tested the code before rolling out to production? How could they blindly assign a mere " " space? Indeed we all asked. To cut long story short, it turns out that back in those Windows 2003 RTM days, a domain controller would happily accept a nonsenscial " " space for a user's Manager property. Since the original developers did not encounter any errors with that type of logic, they probably assumed all the world was at peace with each other.

After patching it to at least Service Pack 1, the "Directory service is busy" error comes into play. The latter problem is actually better, though. Because storing an invalid DN value in the Manager property would later induce unsavoury error and behaviour when attempting to edit the user's properties under the Active Directory Users and Computers administrative console. It was essentially corrupting the AD user data.

So if you are witnessing this error message in your ADSI code, take care no funky values are being offered to the domain controller. Do not feed your goldfish junk.

Visual Studio .NET 2003 web projects: Unable to retrieve folder information from the server

icelava — Sun, 23 Aug 2009 17:03:35 GMT

Just the other day I was attempting to relook at an old web project stuck in ASP.NET 1.1 and Visual Studio .NET 2003. Have retrieved the source files from my Subversion repository into a separate Windows XP machine, I hit an error attempting to open up the web project.

Unable to retrieve folder information from the server

I looked around the Internet and found no relevant resolution to my situation. I eventually did, but totally forgot to log down the reason. It was not until Plip hit the same problem did I make it a point to jot this down once and for all.

The problem is due to TortoiseSVN - the supreme Windows client for Subversion - defaulting to a convention of using ".svn" directories for version control tracking purposes on local directories. Visual Studio .NET 2003 is rather unhappy with the presence of such directories and throws the above ~~tantrum~~ error. In order to work around this, TortoiseSVN settings has an option to use the convention of "_svn" instead, which serves to keep Visual Studio .NET pacified and working properly.

Review: Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build

icelava — Fri, 17 Jul 2009 07:12:16 GMT

When the Microsoft Developer Division sat down to consider the future of .NET development from v2.0 onwards, they recognised the build process in Visual Studio .NET was primitive in its facilities. It had to be re-architected to provide a much more flexible and extensible mechanism. Thus the re-engineering endeavour that brought us MSBuild. Although it was modeled after NAnt and featured some intriguing concepts, widespread adoption was not achieved. As in, conscious manipulation and customisation.

Sure, most developers simply think Ctrl-Shift-B when "build" is mentioned; it remains an invisible compile tool in Visual Studio in their eyes. But for those who did knew the advent of MSBuild, the woefully inadequate documentation prevented many from properly understanding the arcane concepts it brings to the table. Lack of understanding directly affects utilisation. I was one such individual who struggled last year to find relevant material to explain what I needed to know and do to achieve what I thought were pretty common build steps. Suffice to state I was disillusioned and disappointed.

Which brings me to this executive summary: I wished Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build was published last year when I needed it.

This book is what the stock documentation should have been. Sayed Ibrahim Hashimi and William Bartholomew must have realised that - developers were not getting much out of those materials - and wrote the first three chapters of Part 1 to slowly and meticulously explain the concepts and important elements one works with in MSBuild. When necessary, line-by-line details are elaborated, and the MSBuild samples are always accompanied by sample prints of the console screen output as well to illustrate the point. While this is no excuse for relieving folks from trying things out themselves, it runs the extra mile to help me understand the theory since I tend to read while commuting. Being able to finally grasp those elusive concepts was a joyous event.

The book also covers extensibility avenues, teaching the underlying framework and showing how to develop custom tasks and loggers, even how to refactor the MSBuild project elements into smaller files; they give a clearer picture how all these pieces combine together to form the entire build workflow and possible extensibility points for one to inject custom targets and tasks. But this book is not just about the official stock product either; the authors recognise weak points in the current implementation and devote a significant portion of the book to suggest a variety of alternative solutions from third-party add-ons from CodePlex or Tigris to overcome problems that may be commonly encountered by build teams. Differences between MSBuild 2.0 and 3.5 are also noted to provide readers with heightened awareness of what they can or cannot do with a particular version. The last Part that details working with Team Foundation Build is also an extremely helpful segment that I have been dying to know how builds are implemented and managed in Team Foundation Server.

As much as I love this book for filling critical gaps in my MSBuild knowledge, one thing that I did find lacking was a full-fledge demonstration of how to define an end-to-end build project that does different things all based on conditions from the previous steps. Like, invoking code analysis only if unit tests all pass, building and deployment release configuration only if debug configuration passes tests, emailing to the team the statistics or status of deployment, etc. Many of the demonstrations are isolated in their demonstration. While the content has done a fine job explaining the individual concepts, MSBuild as an XML-based semantic still remains highly arcane; more unified samples would have helped many. There is no mention of CruiseControl.NET either, which probably means it is not as popular as I was led to think.

Any build engineer or developing tinkering with project builds, absolutely needs to read this book. It will fill many of the blanks the standard documentation never provided, and widen your search for better ideas to improve your build.

Overall rating: 9/10
Must-have supplement to SDK docs; meticulous explanations; liberal alternative recommendations
could have demonstrated more unified, sophisticated build sequences with conditional paths; no CruiseControl.NET

Authorization Manager with ADAM: 0x80070002

icelava — Thu, 12 Jul 2007 17:01:05 GMT

Authorization Manager (AzMan) is an incredibly helpful feature of Windows 2003 for any development team who seeks to deliver a solid and fluid security framework in their applications. I have experienced its benefits in a past project, allowing dynamic designation of roles and authorized tasks to manage an entire enterprise of users' rights to the system. However, that was not on a web front.

In some upcoming projects, we stand a chance of re-staging AzMan as the bouncer for the ASP.NET web applications we are to develop. The catch, though, is we may not get permission to stash the AzMan policy store directly in the corporate domain. The obvious alternative is to get ASP.NET to refer to an AzMan store located in an ADAM partition. That tutorial was pretty straightforward to execute, when I was using Visual Studio's file-based web site to it; with the built-in WebDev server running as my administrator account. When I took the next step of setting up the site to operate off IIS (5.1), it would bail when I tried to use the Roles class.

System.IO.FileNotFoundException: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)

Despite me assigning the ASPNET account as an Administrator of the AzMan store, I could not overcome this error. I sought high and low for that divine revelation that would explain why ADAM had fallen from grace in this situation, and it was many days later did I obtain a subtle hint as to just what was serving as the road block.

Open up ADAM ADSI Edit. (All Programs > ADAM > ADAM ADSI Edit)
Connect to... the ADAM partition that contains the AzMan store. In my case, a DN of CN=Authorization,DC=group,DC=testdomain,DC=org.
Once connected, it should expose a node CN=Roles. Click on it.
The right pane should list three roles, CN=Administrators, CN=Readers, CN=Users. Right-click CN=Readers and select Properties in the context menu.
The Properties dialog box will expose an Attributes grid. Locate the members property in it and double click the entry.
Multi-valued Distinguished Name With Security Principal Editor dialog appears. Click Add Windows Account... and add in the ASPNET account.

ASPNET, as the ASP.NET worker process, should now be able to read through the ADAM partition to access the AzMan store within.

Signs your colleague may not be a good developer #5

icelava — Thu, 11 Jun 2009 01:53:06 GMT

Critical enterprise batch controller application is called

ConsoleApplication1.exe

End of story.

Signs your colleague may not be a good developer #4

icelava — Tue, 02 Jun 2009 06:32:39 GMT

What does the HTML tag above represent? That's right, a control for a user to tell the browser to upload a file on his/her computer to the web server on page submit.

Now, how should you react when the web developer taking care of this page thinks all that the browser is submitting to the web server (IIS in this case) is merely the file system path string of the file, and the web server would subsequently go back and retrieve the file from the user's computer? Because, you know, the web server knows exactly where the file is on the client's computer.

I struggled hard to explain to her how the HTTP request-response model works. And then it appeared she was likely not the only one who has a distorted perception on the mechanics of the world wide web.... Anybody have a handkerchief? I have tears I need to wipe.

UPDATE

For those who asked, these are developers who have been around for years. They are not fresh grads.

System.EntryPointNotFoundException Unable to find an entry point named GetPropertyHandle in DLL wminet_utils.dll

icelava — Wed, 01 Apr 2009 02:53:07 GMT

So here I am stationed with a huge customer, with a huge legacy .NET 1.1 application base. Oops, did I just call .NET 1.1 "legacy"....??? When one regularly travels at the speed of light, everything else appears to be in perpetual standstill. The rate of progression with Microsoft software is so incredibly swift that those of us who (attempt to) keep up with their pace of development and release sooner or later will forget that the rest of the world have real business objectives to meet rather than blindly upgrade for the sake of upgrade.

But I digress. I do not truly mean whine and bitch. I already do that enough on a daily basis for a variety of other reasons. The main issue I raise here is, with the Internet already moving past .NET Framework 2.0 and into the shiniest of .NET Framework 3.5 SP1 and the luxurious and juicy goods promised in the upcoming 4.0, the amount of information pertaining to .NET 1.1 seems to be evaporating as folks aren't bothered to secure the lid anymore.

And then, ah, the usual software voodoo happens again.

In an attempt to troubleshoot a particular .NET module that has been giving the customer problems since Day One (that is, back in 2004) I attempted to step-run it on my workstation. As with many other .NET applications around here, this one is built on top of a framework asset that my company regularly utilises to speed development by providing all the plumbing functionality. But I hit an odd never-seen-before error:

An unhandled exception of type 'System.EntryPointNotFoundException' occurred in 4imprbcy
Additional information: Unable to find an entry point named GetPropertyHandle in DLL wminet_utils.dll.

In further digging, the framework itself also logged more details in the Event viewer log.

Event Type: Error
Event Source: Framework Instrumentaion
Event Category: None
Event ID: 0
Date: 3/31/2009
Time: 10:26:48 AM
User: N/A
Computer: MYWORKSTATION
Description:
Failed to fire the WMI event 'LoggingLogDistributedEvent'. Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for "ConvertClass_3" threw an exception. ---> System.EntryPointNotFoundException: Unable to find an entry point named GetPropertyHandle in DLL wminet_utils.dll.
   at IWOA.GetPropertyHandle_f27(Int32 vFunc, IntPtr pWbemClassObject, String wszPropertyName, Int32& pType, Int32& plHandle)
   at ConvertClass_3..cctor()
   --- End of inner exception stack trace ---
   --- End of inner exception stack trace ---
   at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.Activator.CreateInstance(Type type)
   at System.Management.Instrumentation.TypeInfo..ctor(EventSource source, SchemaNaming naming, Type converterType)
   at System.Management.Instrumentation.InstrumentedAssembly.GetTypeInfo(Type t)
   at System.Management.Instrumentation.InstrumentedAssembly.Fire(Type t, Object o)
   at System.Management.Instrumentation.InstrumentedAssembly.Fire(Object o)
   at System.Management.Instrumentation.BaseEvent.Fire()
   at Organisation.Framework.Instrumentation.InstrumentedEvent._FireWMIEvent(BaseEvent event_)
-----------------------------------
The type initializer for "ConvertClass_3" threw an exception.
-----------------------------------
Unable to find an entry point named GetPropertyHandle in DLL wminet_utils.dll..

Attempting to search for more details on what wminet_utils.dll is about has been difficult. All I see are archive sites that provide a copy of the file just in case yours get corrupted. Looking at the error message it would appear mine is. This appears to be a unmanaged helper DLL that comes as part of the .NET Framework, located at c:\Windows\Microsoft.NET\Framework\v1.1.4322

I copied over the file located in a Windows 2003 server, which showed a different date and version, but the error still persisted. I tried to match it closer by copying wminet_utils.dll from my colleague's workstation to no avail. For the matter, my colleague's workstation is able to run it without throwing such an exceptional error. Patching to .NET Framework 1.1 SP1 did not help either. Wait a minute, I couldn't even tell from the Add/Remove control panel whether SP1 was already installed previously.

In the end, I decided to uninstall .NET Framework 1.1 this morning and reinstall afresh. "Voom" the sound of the problem being sucked away by the vacuum cleaner as I clear the old debris. The new installation of .NET Framework 1.1 got it running again. Now was it really corrupted? I subsequently applied .NET Framework 1.1 SP1 again and smacked into the same error again. Hmmm, what is it about SP1 that may cause System.Management.Instrumentation.InstrumentedAssembly or TypeInfo to have a misunderstanding with wminet_utils.dll?

Unfortunately, I do not know and I do not have the time as of now to look into this further. I have problems to fix for my customer.

Timeout deploying assembly to SQL Server 2005

icelava — Thu, 28 Dec 2006 14:36:06 GMT

Developers who begin to bloat the size of their assemblies destined for CLR-enabled SQL Server instances may be hit with the following timeout problem when attempting to deploy from Visual Studio to a remote server:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

This happens when SQL Server cannot complete the first statement to drop the old assembly (a very lengthy statement) within the 30 seconds Visual Studio gives it with LOCK_TIMEOUT. Run a Profiler trace on the server when the deployment takes place to witness this. What I could not easily find was how to adjust this timeout tolerance; it certainly does not exist in the database project's Database or Deploy sections, or any other for the matter.

And here is a case when one has to step out of the "Google/MSN comfort zone" and manually search forum boards that search engines have not crawled well. One MSDN Forums thread talks of this very issue and the place to get Visual Studio to give some slack:

From the menu Tools > Options...

Expand Database Tools > Query and View Designers

for Cancel long running query, either uncheck it, or set Cancel after to a longer period.

Counting queue items in MSMQ

icelava — Fri, 03 Jun 2005 16:02:09 GMT

Don't you just <tone type="sarcasm">love</tone> it when the .NET Framework fails to provide some functionality that you need in order to accomplish a simple task?

In the project I'm working on currently, I am looking to implement MSMQ (Microsoft Message Queuing), touted by many to be one of the most underrated but useful technologies, as a reliable back-logging mechanism for items that cannot be written to database should the network connection fail.

The .NET Framework has a wonderful System.Messaging namespace with the classes required to send/receive messages to/from queues, but the problem is there is no facility for me to even check if a private queue has items in the first place, much like how the MSMQ MMC console represents. Woah. Talk about over turning your car because of a small stone.

It is at such a time where one has to painfully revert to the APIs of old and muck around in unfamiliar WIN32 or COM territory. Having become a professional developer only with .NET, these situations become frustratingly time-consuming activities for me - I've been there more times than I like. Thanks be to God, we still have our world of legacy (ok, maybe that's a harsh word) developers who are willing to share these information.

I (or Google, actually) managed to hit almost on the dot with the blog of this MSMQ guru, Yoel. Three options he gives, and I decide to take the second idea (with Microsoft Message Queue 3.0 Object Library) since it appears to be more elegant than the first, and actually having some code over the third. Hey, .NET is suppose to make COM InterOp [almost] seamless so it shouldn't be too hard!

Well it's gonna take more effort on my part if this is going to work as I need it too. First of all I don't even know what the code is really trying to do. If you Google for "MSMQManagementClass" the only 2 results returned are Yoel's own blog pages. Looks like MSMQ is really underrated. I had a tough time trying to figure out what those "o" parameter variables refer to.

Of course, the truth is one should be searching for "MSMQManagement"; the prior is a COM InterOp wrapper name. Once I got some proper Platform SDK reference I trialed and errored with the parameters (since I only wanted to work with a specific queue) until I could reliably grab the queue without provoking any COMException and "generic COM errors".

Some hours gone by so I can settle down on this code. Just so i can count.

object machineName = Type.Missing; // Set this to make parameter optional.
object noFormat = Type.Missing; // Set this to make parameter optional.
object pathName = @".\private$\QueueName";
MSMQ.MSMQManagementClass msmqMgmt = new MSMQManagementClass();
msmqMgmt.Init(ref machineName, ref pathName, ref noFormat);

MessageBox.Show(msmqMgmt.MessageCount.ToString() + " items");

Signs your colleague may not be a good developer #3

icelava — Sun, 22 Mar 2009 15:50:07 GMT

It has long been my suspicion, that many organisations do not permit their application source code to be copied out of their premises, not because of security or IP reasons, but to just save themselves from sheer embarassment.

Honourary members of the court, allow me to present exhibit A

            }
          }
        }
      }
    }
}
}

For obvious reasons, I am not allowed to expose more of the evidence. So let me fill in the details and explain that is at line 565 of a C# method. Yeap, seven levels of branching code logic. But wait, there's more! That is only half way through the method; it continues for some three hundred lines more. Seriously, this is not the first time I have had to deal with such labyrinths of code. I have seem worse in past projects. And I know I have also not seen the worst of technical debts yet. This has been a problem since the beginning of software development, and its recurrence to this day is still oh so common. Unfathomable.

But you know what the real problem is? No matter how many times I deal with and fix such abhorring, criminal works, it has not gotten one bit easier for me to read and understand what were going on with the original programmers' minds. Messy complex code continues to remain messy complex code. Unlike the processes of nature, they do not erode and decompose into simpler substances over time. I am highly distressed that no matter how much I learn to write high-quality readable code, it does not help me to read rubbish code. Like what really can an expert chef do for rotten food. In the absence of original requirements documents, it is near impossible to figure what the code is trying to do, for what reason.

If your colleague's toolbox only contains primitive implemnets of if-else, switch-case, nested for-loops for unending ArrayLists and DataSets, beware. It is safer to socialise with lepers. For such programmers produce ultra contamination that strike deeper than gamma rays can into your brain the moment you read their code and train of thought. Thoughts that never consider how to make this simpler and easier to read. Thoughts that do not figure how to slice the concerns and abstractions into bite-size chunks so they can be dealt with individually. How one slots and organises his/her thoughts is of critical importance.

Just so, you know, that you may have to read the code again.

Refactoring? Well let me inform there are more flaws to the logic and design than a couple of code rearrangements can fix. Therefore it still boils down to my die-hard opinion that interviews need to include some practical programming exercise so that candidates' programming styles and mentalities can be observed and assessed. When you hire hands to do work, you jolly well better test the very skills that pertain to the work that must be done. Would you hire a violin player without hearing him/her play?

Review: Simple Architectures for Complex Enterprises

icelava — Sat, 31 Jan 2009 07:12:16 GMT

The general approach to any grand IT problem is to break it down to smaller manageable pieces. Pieces that our pathetically puny brains can contain and work on at a time. Any decent software developer would have known that. And yet, we still continue to produce massive, monstrous, monolithic code that is a complete beast to interpret, comprehend, and modify. In other words, a mesh of unmanageable complexity. There is without a doubt such technical misshaping contribute significantly to the schedule and budget overrun in way too many large projects, and ultimate failure.

But what am I talking about? This book is not about software applications. As an enterprise architect, Author Roger Sessions takes us up several floors to show us where he believes all these complexity evil germinates - the failure to control the complexity of IT inter-system communication across the organisation. He writes this volume to explain the problem of complexity can be illustrated via mathematical models, and purports that the application these mathematical exercises and further concepts of organisation will help divide the enterprise into simple easy pieces.

That is a rather mighty claim. Is this for real?

Roger Sessions starts out strong. He begins mentioning existing methodologies and frameworks used to organise architectures in the present industry and highlights rather glaringly the missing piece in all of them - the deliberate effort to ensure the output of the work is simple. The next two chapters quickly move on present some simple real-world scenarios (like a rubik's cube, chess games, team and store organisation, etc) and then the math behind them, on how dividing them - partitioning - into smaller pieces of a bigger whole helps to solve the problem they present in a much less troublesome manner. The mathematics introduced is simple enough to understand and convincing. But somehow the lessons would be re-taught every now and then; I found the repeated explanations to be redundant and approaching incessant. It is almost as though the author fears the readers may not be convinced enough and needed reminders. Or there is the assumption the intended audience largely failed elementary math in school.

As convincing as the principles behind the math are, my disappointment set in when the transition from pure math theory into real-world business modeling began. If you think it sounded too good to be true that real-world architecture can be tackled with simplistic mathematical models, well, it is. Even Roger Sessions himself admits that real-world circumstances is in fact, not that simple. The problem with the absolute black-white nature of mathematical theory is it excludes many (grey) inter-object relationships or channels that real-world organisations would inherently possess; they cannot be blindly ignored. Take for example, the Five Laws of Partitions

First Law of Partitions - Partitions must be true partitions.
Second Law of Partitions - Partition definitions must be appropriate to the problem at hand.
Third Law of Partitions - The number of subsets in a partition must be appropriate.
Fourth Law of Partitions - The size of the subsets in a partition must be roughly equal.
Fifth Law of Partitions - The interactions between subsets in the partitions must be minimal and well defined.

With such vague "laws" I predict a chasm of opportunities for unending subjective debates over what "appropriate", "equal size", "minimal", or "well defined" can truly mean when it comes to discussing how to partition a real organisation into smaller units. Therefore the fourth chapter's technique of Autonomous Business Capabilities (ABC) did not resonate well with me as I pondered how this applies to real departments and divisions. It is just not that simple. However, Roger Sessions' intention is squarely - and rightfully - focused on breaking things down simple enough to benefit the business.

On a side note, I found his deliberate avoidance to discuss application systems somewhat isolative. As a software developer, I find many of the principles he puts forth are directly applicable, and even taught, at the level of software architecture and design. Like it or not, the lifeblood of any enterprise is the myriad of software applications; keeping their design simple is as important as keeping the enterprise simple. In fact the SIP (Simple Iterative Partitions) process he recommends resembles Agile practices a lot. Somehow, I get the feeling Roger Sessions has forgotten failure in IT projects is contributed by many things happening at all levels, not just enterprise architecture alone.

It is difficult to label this book as truly seminal; due to the various falling pieces, I cannot feel the utter greatness. But don't be deceived - it has been a good mind-stretching exercise (not mind-blowing). Roger Sessions has presented some eye-opening ideas that allowed me to gain new light in this argument for simplicity. His message is clear - there not enough people consciously considering simplifying things they work on; and accomplishing things by smaller projects of iterative sequence. I wholeheartedly agree on this. If the word "simplicity" never flashed across your mind (are you reading this, CIOs, CTOs, and architects???) while you were thinking through architecture or design, you need this book to yaw yourself in the right direction.

Overall rating: 7/10
Refreshing perspective; interesting model & approach for architecture; gets the point across
Repetitive; model not 100% mapped to real world; concept not 100% new; the IT problem spans across more than one area