Operation could destabilize the runtime
It turns out that the metablog.ashx file will not run in a Medium trust environment. If you can make changes to the web.config file on your host server, you can fix this by changing the level attribute, in the trust element, from Medium to High (see this MSDN item for more info). This did fix the issue, but it wasn't as straight forward to determine the root cause of the error as it should have been.
I'm the Igloo Coder and I'm out on the town for some Indian tonight so please excuse me while I break into a Bollywood dance scene.
I'm the Igloo Coder and I was shocked to hear Scott Hanselman describe a local bloke as his hero.
The other thing that was interesting was his adamance that the Model View Presenter pattern was the only way to create a system. I've very little experience with this pattern, but his passionate arguements and explaination of the pattern has made me seriously consider it's benefits and possibly has start to convert me on that front too.
I'm the Igloo Coder and Jean Paul has an open invitation to sit next to the whale oil heater and I'll just sit and listen.
colinco - Avanade Integration Pack for Microsoft Enterprise Library Released
Avanade.IntegrationPack.EnterpriseLibrary.NOSOURCE.msi (1.08 MB download)
I'm the Igloo Coder and I have to go configure my way into some better caches.
I'm the Igloo Coder and I'm going to delete something else while I'm on a roll.
In his keynote today [Thursday March 16th, 2006] at SDWest 2006, Rick LaPlante announced that we’re releasing Visual Studio 2005 Team Foundation Server tomorrow. Last year we took the tough decision to disconnect Team Foundation Server from the rest of Team System, but promised that Team Foundation Server would ship in the first quarter of this year, and we’re delivering on that promise.
I'm the Igloo Coder and I've got one hand on the keyboard.
I'm the Igloo Coder and I'm going to start doing some work on the ice flows outside.
I'm the Igloo Coder and I'm having PM Boy flashbacks. Someone pour me a drink.
I'm the Igloo Coder and I'm wondering if they'll charge more to let my dog team stay in the room?
I spent part of the weekend working on upgrading the blog to Community Server 2.0 for .Net 2.0. I didn't have any problems performing the upgrade (other than the fact the upload of the new application took hours).
The only problem that I ran into during the process was getting the blog reconfigured to run from the root of my server. There is a helpful blog posting by Dan Bartels that got me started but a few things were still non-functional when I completed.
When I tried to open archived month folders, specific posts and the comments sections, among others, I would get redirected to a page not found error. It turns out that the URLs being substitued for these links did not include my first level domain in them (i.e. http://archive/2006/03.aspx instead of http://www.igloocoder.com/archive/2006/03.aspx).
To fix this problem I opened the SiteUrls.config file and made the changes to some of the url elements. In the path attribute for the elements there was a value of ##blogdirectory## and I replaced that with blogs/. I didn't make this change in all locations, but rather changed one at a time, as I found incorrect URLs on the website, and retested them. I'm sure that some of the values I neglected to change will need to be changed in the future as I find places that the site is not working.
I'm the Igloo Coder and I think I've been hogging the seal skins at night.
I got an invite to Windows Live Messenger beta today. I’ve installed it and started to play tonight. I got all excited and spread around the invites. Once I had some people online I started to say how I really like the animated backgrounds, the offline messaging and the VoIP stuff. My bubble was burst when I was told these things all have existed in the current version of different messenger products. I was so happy crawling out from under my rock and then all of a sudden….Wham!…the damn rock falls on me.
I’m the Igloo Coder and I think I’m stuck.
John Bristowe is coming to Edmonton on the 14th of March. He is doing a presentation on WinFX for the Edmonton .Net Wizards User Group. Here are the instructions on where to find the meeting. Hopefully this is a trend to the good for the user group as things have yet to really gotten off the mark for it.
I’m the Igloo Coder and I’m why the fuck is it called an Eskimo Pie when it has nothing to do with the eskimos?
Seems that Mike over at Fire in the Hole has decided to blog about developer management. His first series (Lazy managers are good, Don’t panic, delegate, Two more stories on lazy managers) discusses how to be a lazy manager. Is it odd that I see him as being an expert already just due to the fact that 2 of his first 4 posts were posted either during the work day or suspiciously close to the end of it? Regardless, good stuff to read through if you have to, or could be doing, delegation.
I’m the Igloo Coder and if I catch Sir Paul and his ho out on my ice flow again, Danny Williams and I are going to turn the clubs on their fuzzy little asses.
I’ve been working on this side project using .NET 2.0 for the last 6 months and some of the features are really starting to grow on me. The project is a WinForms application which provides a nice contrast to my day-to-day web development. Most of my previous forms development was done in VB6 which, although a decent tool, did leave a lot of things up to the developer.
In the last few months I’ve really started to like the new WinForm controls that are bundled with Visual Studio 2005. If you use Panels, Splitters and Flow & Table layouts in combination with the Dock, Anchor, Margin and Padding properties on controls, it is possible to completely eliminate the need to write any resizing code.
The example that I’ve worked with is a dynamic database driven form that will load up a number of control pairings (a label and another data entry control). In my previous, VB6, life I designed a form like this that had thousands of lines of code that managed the location of the controls, the spacing between them, their sizings and finally the location of the Save and Cancel buttons on the bottom of the form. Oh, and don’t forget to write some code to resize the form itself so you don’t end up with a massive block of dead grey space, or, worse yet, controls being cut off by the edges of the form.
I was able, in a weekend instead of a month, create a dynamic, sizable form that has absolutely no resizing code. Imagine you have 100 such forms in your application and each one has, on average, 250 lines of code to handle resizing. That’s 25,000 lines of code that you need to maintain, and resizing code is notoriously difficult to maintain. Say you can take 50% of those forms and implement the resizing without any code. Not only have you increased the stability of the software, decreased it’s brittleness and saved some poor developer a tonne of unenviable work, but you’ve also reduced the amount of system maintenance that you will have to perform.
Not such a bad thing eh? Check out the MSDN articles on the following topics for some more information:How to: Anchor and Dock Child Controls in a TableLayoutPanel Control
How to: Anchor and Dock Child Controls in a FlowLayoutPanel Control
If you want a good read on WinForms development check out Programming Microsoft Windows Forms 2005 Edition and read chapter 3 on Panels and Dynamic Layout.
I’m the Igloo Coder and my ship has Docked, Anchored and we’re calculating the Margins.
In the past I’ve worked on a lot of reporting solutions. My most recent work project has no reporting component which is contrary to what I think software needs. If your system is collecting and storing data, your users will most likely want to get that data back out in some meaningful way.
I’ve seen reporting solutions be as simple as a grid listing in the software itself that can double as a report when printed (i.e. a Customer Listing report). I’ve also built a couple of systems that were database driven solutions which could dynamically create a selection criteria window, assign the user selections to a T-SQL statement and alter the appearance of the report formatting based on database entries (see Crystal Report vs Active Reports for brief descriptions).
Currently I’m working on a side project that uses all the newest technologies. The application is written in C# 2.0, the database backend is SQL Server 2005 and the reporting solution I’m using this time is SQL Reporting Services 2005. I’m intending on writing a fully detailed account of Reporting Service in the next short while that will be provide the final comparison between SRS, CR and AR.
On this side project I’m once again working on a fully database driven solution, but I’ve made a few changes to the way that I’m structuring it. One of the most significant changes is that I’m no longer using T-SQL stored in a database field as the source for the reports queries. Instead I’m using stored procedures (the name of the procedure is still stored in the database) and parameters. One of the reasons for choosing to put the report queries in the database was to allow for the report to be easily altered without need for software upgrades.
For a couple of reasons I think the use of T-SQL was flawed. One of the reasons was that it didn’t really make the maintenance all that much easier. SQL statements stored in a database field were tremendously difficult to recover, reformat, alter and upgrade (primary difficulty being the reformatting). Another reason was that we did, on occasion, create SQL statements that were larger than a varchar(8000) field could hold. To overcome that we used a text data typed field, but it added more difficulty to the retrieval of the queries. Because we were inserting the selection criteria of the users straight into the base T-SQL queries, we had also opened up the possibility for SQL injection attacks.
By using the stored procedures with parameters I have significantly reduced the possibility of a SQL injection attack, the stored procedures are much easier to work with through the upgrade cycle and flexibility does not appear to have been compromised. The only thing that has become more difficult is the passing of multi-valued selections into the stored procedures. There are ways around this and I will outline the one I’m using in a future post.
One of the things I did on the last framework I built was create a utility program that allowed for the creation and editing of the database components of the reporting solution. I’m planning on creating this feature again, but this time with the additional ability to create an easy upgrade process for disseminating the new, or altered, reports.
Currently this reporting framework is not as functional as the ones I’ve built in the past. It still requires the ability to alter the report layout and groupings, as well as the ability selection criteria to trigger changes in the state of other selection criteria. Once these things have been created, along with some sample reports, I’m planning on posting a thorough article on the framework and it’s portability.
I”m the Igloo Coder and I’m reporting today from deep inside the bowls of a mink whale while I wonder which end of the whale I will be extricated from.
For about 11 months now I’ve been at my current employer. One of the things that has been different in that time is that the development team has had, and been able to request clarification on, software specifications. In tribute to my experience with specs, I’ve decided to blog about my thoughts on them. By no means is this intended to be a comprehensive review of software specs. If you want that, read Software Requirements 2 by Karl Wiegers.
Specs are so much more than documentation on how the system should work. In addition to providing a strong foundation for the development of the intended software, specs will allow for the resulting software to be thoroughly tested, comprehensive documentation to be written and the development of training materials. Probably the one thing that I’ve seen thus far that out ways any other benefit of having good specs has been the ability to use them to control scope creep.
Like any document, a software spec is only as good as the content it contains. Not only does the content needs to be comprehensive and accurate, but the document also needs to be constructed in a searchable, scalable and readable format. Because software specs can, and should, be used to create so many additional documents they also need to be written so they do not cater to any one specific role in the software development process/team. Software specs also need to practice good encapsulation to ensure that contradictory specs don’t exist and, so that when the inevitable change requests start pouring in, the changes can be made in one location.
Document formatting is a finicky thing, even if it isn’t for specs. Everyone has their own idea of what is best. Regardless of the decided format, the document needs to be clear. If possible, segment the contents of the document into sections using the formatting power in MS Word and then use the Table of Content feature to create a searchable outline. In the end, decide on a format and refine it when necessary. Even if the format is not perfect (few things ever are) maintaining consistency will go a long way to ensuring communicating effectively with the spec’s intended audience.
The contents of software specs will vary depending on the type of system and the type of contents being spec’d. Software specs might include any number of things. For example, a UI spec document may include information on control tab orders, data entry validation, and data display formatting. The one item that seems to be missed regularly from these documents is a section that outlines what to do in exceptional circumstances. When we create software specs and envision the system at it’s completion, we don’t think about how to handle situations that may break it. Always ensure that there is a section outlining these situations and how to handle them. If you think that there aren’t any, review the spec again because you’ve probably missed some.
The real reason for writing the software spec’s is to facilitate the transfer of knowledge between people in different roles during the software development process. You must know the audience that you are writing the document for. Yes, it could be read by anyone in the end, but if you write it for the broad audience it will not be informative enough to be helpful to the primary audience. Imagine trying to read a document meant to describe business process and practice that has been written focusing primarily on the technical implementation of said business process. It wouldn’t be informative to a business user and possibly would cause more confusion then it would answer questions.
One of the ideas of OOP is encapsulation. This may be the one case where business can apply programming practices to it’s daily work. By robustly encapsulating software spec’s, the writer offers distinct segmentation of the information provided by the specs. Encapsulation of spec documentation will also reduce the possibility of specific items existing in multiple places with multiple contradicting definitions. General, system wide specifications should be defined centrally and those spec documents should be referenced rather than the information repeated.
If you disagree with what I’ve written or if you have something to add, leave a comment or drop me a note.