This particular blog has been dark for some time. I'm active elsewhere now: follow me on
twitter or read more on my
tumblr account.
This is a public service message for any tyro BizTalk developers (like us) who are getting a HAT message along the lines of Loading document specification [some schema] from assembly [some assembly] failed. Verify that the schema is deployed properly and that the schema assembly implements the document spec.
Scenario: You've got a nice remote BizTalk host server installed and running. You're developing BizTalk projects locally on your PC in Visual Studio 2003. You're using VS2003 to deploy those projects to that remote server. The project builds fine. The project deploys fine. The receive ports and send ports are all fine and dandy.
You drop a test message into a receive port. It disappears into the messagebox. You go and wait by the send port with bated breath. Nothing appears. You wait a little longer. The absence of messages frustratingly persists.
Finally you accept that something might have gone wrong, so you open the HAT. You check out the Messages Received in Past Day. There it is: 'Unparsed Interchange'. You open the message flow and you see that BizTalk in all defiance of common sense and decency has been unable to find a schema to match your message.
BizTalk is obviously wrong, because you strong named your assembly and deployed it. You even made sure that the destination BizTalk server was correctly set in the project properties.
Let me interject at this point. It's more than possible that your carefully crafted schema made it to the remote server, but simply didn't get into the remote GAC. You see, the Deploy functionality in Visual Studio 2003 can't do a remote GAC install. Instead it helpfully installs the assembly in your local GAC, right where you don't really need it.
So BizTalk wasn't lying after all. It can't understand your message because the schema isn't in the GAC.
The solution? To get the BizTalk assembly (and any non-BizTalk dependency assemblies for that matter) into the GAC on the BizTalk server, you need to run gacutil.exe, btsdeploy.exe or the BizTalk Deployment Wizard locally on the server.
It's all in the documentation, apparently. Here are some helpful links:
How Assembly Deployment Works
BizTalk Power Toys. You need these.
A BizTalk Auto Deploy project at GotDotNet
Notwithstanding the fact that this blog is almost a wraith-like version of its former self, and largely resident in the same shadowland occupied by OS/2 Warp and Lotus Notes, you may like to know that I am posting here.
All very interesting stuff, almost none of it anything to do with .net.
Our website runs on a pair of colo-ed web servers that get syncronised together by Application Center. Let's call the servers Andy and Betty (names have been changed to protect the innocent). Both sit behind a server iron that does load balancing.
Website updates get published to Andy via an automatic FTP service. That works fine, although it can be a little sluggish.
After the files appear on Andy, Application Center pops up and says 'Hey, time to copy some files and permissions over to Betty!'. And lo, the files are copied and Betty looks the same as Andy.
However, we have noticed recently that Betty has not been looking the same as Andy. Specifically, a number of zero-byte files have appeared on Betty, where their equivalent back on Andy are perfectly okay. Mostly these are GIFs and PDFs, but we have had a few important pages get zeroed out.
Unfortunately there's no evidence in the logs about why this is happening. It's not consistent, and we have not been able to replicate it. At the moment we're just letting the world see Andy, and Betty is invisible to the public. Andy is man enough for the job but we'd really like them both to work in partnership.
While we try to work out what's going on (with help from Microsoft), I've written a Windows service app that detects zero-length files. It monitors the file system and if any files become zero-length and stay that way for more than a few minutes, the administrators are alerted. It's a simple little app; if anyone wants to see it or have a copy, they're more than welcome. It's in C#.
If anyone can shed any light on our little problemette described above, we'll be very grateful.
I've been on one or two 'death march' projects during my years in IT. Each time I just buckled down and got on with it, and came out the other side saying "never again"
But no project I have ever worked on, no company I have ever worked for (even Razorfish, bless their little cotton socks) has ever treated me so badly as EA appears to treat its staff.
Please read this article by ea_spouse on livejournal.
Ok, the new msn search is working okay this morning. I haven't noticed any US bloggers commenting on it being unavailable yesterday, so perhaps it got working again by the time they hit the office.
It's running fast and looking fine. I ran a couple of search terms that I run on Google from time to time, and got a longer set of results. Also ordered slightly differently. Better results? Too early to say.
The tuning feature looks interesting: hit Search Builder|Results ranking - you can prioritise/deprioritise the accuracy of the match, the popularity of the results and the freshness of the results. I can imagine that this would be useful when struggling with large result sets. We'll see.
Perhaps it's time for a sea change on my desktop - a move from IE + Google to Firefox + MSN Search. Yes, I know it's a weird mix, but then I've never cared about the whole MS is good/MS is bad thing. I just like products that work. Strange, eh?
Microsoft launched a beta of the new MSN search today. Almost quivering with anticipation, I headed over to http://beta.search.msn.com to try it out.
It barfed. Repeatedly.
For the last hour (13:00 to 14:00 GMT) the site has been returning "This site is temporarily unavailable, please check back soon."
Not a great way to start. I appreciate that the launch team are probably all at home tucked up in bed after pulling some very late nights, but you've got to care about how new products are perceived outside the US, as well as inside.
The msnsearch team have also launched a blog which suggests that the service is 'now available'. This is an interpretation of 'available' which I have not come across previously.
I will be 'checking back', but probably tomorrow.
Edit: Wim is also experiencing problems, but he got further than me.
I've taken my little Trackword game a step further. I've implemented a Daily Trackword page which selects a random trackword for the first visitor of the day, and then retains the trackword and the grid ordering for all future visitors that day.
The next step for that page is to build in stats, so players can see how well each other has done - ie who the found the Trackword quickest, who has found the most other words in the grid.
The main reason for the Daily Trackword page was to build an RSS feed containing the Daily Trackword game. That's also live now, at http://www.laurencetimms.com/rss.aspx. The feed shows the five most recent daily games. You can choose to play the Trackword just from the feed (using only the power of your mind, or maybe pen and paper), or click the link to open the relevant Daily Trackword page.
I realise that the dateline on the Daily Trackword feed & page is coming out in German! My host space is in Germany, and I haven't specified the culture for the date formatting. One of those things you never expect to have to do...
Main discovery: the RSS schema is really simple and obvious. Populating it with some interesting content is harder!
For this RSS feed I pull the Daily Trackword records from the database and assemble them into a DataTable object which is formatted according to the RSS 2.0 spec. I then bind the DataTable to an ASP.NET Repeater control and use DataBinder.Eval to pull the table values out into the Repeater contents. It's an elaboration on the approach described by Scott Mitchell here.
It's all a bit rough and ready, plenty of scope for refinement!
I wonder if this is the first RSS 'game'? I'm sure it's not. Maybe I'm early to the party though; that's good enough for me
Finally my little Trackword game has found a host. Check out http://www.laurencetimms.com/trackwordhome.aspx
It looks very v1.0 at the moment, but I have big plans including:
- RSS feed (daily game in an RSS feed, including the answers for the prevous day; user can play the game from the visual content in the feed or can follow the link to the actual page to play the daily game with the full UI)
- scoring
- foreign language versions (German first)
- save game option
- hi scores table
- 4x4 grid for people with way too much time to play word games
- make the damn thing look prettier
Scott Guthrie follows up his excellent blog entry about testing ASP.NET 2.0 with a lot more detail about the testing software, scripts, hardware and all that good stuff.
These people do testing on an industrial scale. Just check out the lab photo!
After a long silence - what has the guy been doing recently - Scott Guthrie has posted a great Whidbey/ASP.NET 2.0/Visual Web Developer update which gives an excellent insight into the behaviour of a large development team approaching a major milestone. In this case the milestone is Beta2.
Check it out.
How many words of three letters or more can you find by tracking from one square to the next, going up, down, sideways or diagonally in order? You may not go through the same letter square again in any word. No proper nouns or foreign words. What's the hidden nine-letter word?
Trackword is a game written in C#, using a component architecture which means it's fairly easy to render it to HTML or to Winforms. It uses a SQL Server-based dictionary.
The core game component also has functions for finding all the possible words in the grid. That was fun to code.
I'm happy to share the code with anyone who is interested - constructive criticism is always welcome.
I'm stunned. But this is what it said, so it must be true.
Which File Extension are You?
Paul Ballard on TheServerSide.net says SQL Server 2005 Delayed
The implication is that VS2005 will also be delayed because of the close relationship between Yukon and Whidbey.
Frans Bouma is upset about this.
Fabrice claims that everything he needs out of Whidbey has been ready for months and why should he wait for some pissy new database? (ok, I implied the last bit)
Robert McLaws reiterates dependency issues (Yukon, .NET 2.0, Whidbey) and says nothing has really changed since Whidbey was always going to be May-July.
In comments it boils down to a likely scenario of VS2005 being released 3-8 weeks before SQL2005 but probably being available for download from MSDN for some time before.
Hands up everyone who's going to start cutting live code with the VS2005 Beta.
I am iCan. Which is this - interesting!
What are you?
Apologies for the silence. I know you've all been missing me (!)
After 9 years of tube hell, I left my job in central London and have moved to the RSPB in leafy Bedfordshire, a mere 10 miles from home. The commute is blissful by comparison and I'm getting nearly two hours a day extra at home with my family.
So that's a result.
Anyway, more Visual Studio stuff coming from this corner soon, since I have lots of interesting work in the pipeline.
In the meantime (whispers...) I've got a mere 5 gmail invites that need good homes. If you want one please contact me directly at my gmail dot com address which begins laurence dot timms. Cheers.
Ok dudes, I'm out of the office for two days. In the meantime I humbly invite you to enjoy the b3tazoo.
Those of you who know and love b3ta will know what this is about.
For those of you who don't: b3ta is a lovely place where people muck around with images. Some of the best paintshopping to be found on b3ta is the melding of one animal with another to create such beauties as the leopardfrog, the spidraffe and the orangutangula. The b3tazoo has them all collected in one place. Enjoy.
This is a word puzzle called a trackword. You have to find the 9-letter word hidden in the grid by tracking across each letter in turn up, down, across or diagonally. Can you figure it out? This one is fairly easy. Once you've figured out the trackword, see how many other words of 3 letters or more you can find using the same rules.
Anyway, I'm writing a component in C# that will generate a trackword grid from a dictionary, build a GIF of it and post it to my website each day. The component also has to work out all the possible words in the grid to allow users to check their solutions.
Problem 1) The grey background of the GIF always comes out in 16 colours or something. How can I get it to be high colour? I'm using this code to create it:
Bitmap newBitmap = new Bitmap(150,150,PixelFormat.Format64bppArgb);
Graphics g = Graphics.FromImage(newBitmap);
g.FillRectangle(new SolidBrush(Color.LightGray), new Rectangle(0,0,150,150));
// do some drawline and drawstring stuff
newBitmap.Save("trackword.gif", ImageFormat.Gif);
Problem 2) I've worked out an algorithm for scanning the grid and finding all the possible words in it, but it's not perfect. To be honest, it's all a bit Heath-Robinson. Does anyone know of any code libraries that do a similar kind of thing? I don't like re-inventing the wheel if I can avoid it.
Thanks all.
You may recall that I whined about the Microsoft UK on-line event booking process. Microsoft UK responded to my moans and garnered a bit more detail about my complaints. I was satisfied that they recognised the issues I listed, and in fact were already working on some of them. No doubt the process will improve!
Apologies to MS UK for not mentioning their response before now. Very unbloglike of me.
Anyway, after all that whingeing, I have to cancel my visit to sunny Reading this month because I'm going to Lübeck on the Baltic coast of Germany to spend two days doing long-term planning with my German colleagues Hela and Axel. Ah well.
Just seen this post on David Findley's blog - a survey on the 10 reasons why software bugs occur. It's fun to do the survey but the main reason I'm referring to it is because it's a very succint encapsulation of the root causes of buggy software. Here's the list for quick reference:
10. Poor training. (coding, business analysis, tools, infrastructure etc…)
9. Laziness – the desire to use the easiest to implement solution.
8. Compromises made in req/design to meet delivery schedules.
7. Coding methodology failures such as bad or missing error handling.
6. Vague or incomplete requirements.
5. Misunderstanding of the requirements.
4. Poor design.
3. Misapplication of technology. (Components, products, techniques)
2. Lack of testing
1. Change: to requirements, infrastructure, tools etc., because it introduces the likelihood of all of the above to happen.
As David pointed out, each one leads to the next, all the way to #1.
But the story doesn't end there. As I pointed out in the title, Change causes bugs. What's the solution? Unfortunately the answer is not 'lock down requirements' or 'ignore new user demands'.
When you are developing an application you are providing a solution to a problem which may not be fully understood, clearly defined or unchanging. Does this mean you should ask everyone to stop doing business while you write the app? Of course not. The development team has to be able to continually adapt to changing requirements in a controlled manner, understanding the need for change, assessing the risks involved, determining the new priorities and plans and communicating these with the project team.
This is not an easy task.