icelava.net

why be normal?
Welcome to icelava.net Sign in | Help
in Search

Woe to he who wants to know more about his build process

Last post 08-21-2008, 6:11 by icelava. 0 replies.
Sort Posts: Previous Next
  •  08-21-2008, 6:11 4358

    Woe to he who wants to know more about his build process

    Want to be a more knowledgable developer by setting Visual Studio's output window to automatically focus upon activating the Build process? So that you can observe real-time details on what happens behind the scenes with MSBuild and the compilers?

    Well, curses to you for wanting to know so much! You should remain an unmotivated uninterested programmer!

    I am now involved with a team looking at a BizTalk implementation. I for one have not worked extensively with BizTalk before, so one of my first activities this week was to setup a new virtual server operating BizTalk Server 2006 R2. It was not as smooth as expected, given the sheer number of software that needs to be installed prior to bringing in BizTalk Server itself. Nontheless I got everything in and proceeded with tutorial lessons to get myself up to speed with BizTalk concepts.

    Although slow, things were moving along fine, until last night's chapter about developing orchestrations. Visual Studio 2005 Professional, which is required to develop and deploy BizTalk projects on the server, would run (devenv.exe) the CPU 100% in an afterburner effort to increase my electricity bill. Thank God for the Kill Process feature. But, it was getting to a state that of consistency. All that because of a single orchestration object in the BizTalk project? What's up? Is it because Visual Studio was not patched up to SP1? Fine. I'll apply it.

    Errors abound from the installation process. Did I mention Visual Studio 2005 SP1 is one of the most incredibly slow patches, ever? Even service packs for the operating system install faster. Each time I try to troubleshoot the SP1 process means an hour or so lost on this virtual machine. I gave up for the night since it was past 2AM. It was only late in the next morning did I remember Windows 2003 has a problem accessing insidiously large MSI/MSP files. Finally, SP1 could be delivered for Visual Studio. Finally, lunch time.

    So now that I have SP1, I can continue my quest learning BizTalk. Only if I was right. I was not. Still entangled in CPU chains and vines, I desperately searched around for explanations. This (spanish?) blog entry gave a first hint as to what might possibly be the cause. This must be it, I thought, without considering that my first theory was wrong. I went through the hassle of contacting Microsoft PSS to obtain the fix, so that I can confirm that my second theory is also wrong. Nuts.

    What the bloody heck? Sometimes, we should learn to resist the overwhelming branding of Google and search the MSDN forums first. Fellow sufferers developers reveal how the workaround can be so simple and perplexing - do not expose the Output window when building BizTalk projects. It is related to the above KB issue, but unfortunately not fixed by that patch. I am truly amazed how outputting text to a text-based window can do such outspread damage.

    It is time to go home for dinner. One sweet day (and a previous evening) wasted on a Visual Studio bug. That is Rapid Application Development for you.

View as RSS news feed in XML
Powered by Community Server, by Telligent Systems