Why code generate something after it is already written?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_code_generate_something_after_it_is_already_written.htm]

If you've already written something, why go back and code-gen it? There could be a couple reasons:

• You're going to write a lot more of it, so you might as well leverage code-gen for all that existing code.
• You need to extend it with more functionality. Sure, the current stuff is already written, but you need to add new (tedious) features, like recording which properties of a class have had their setters called.
• You want to make it easier to maintain. Manually-maintained code counts as technical debt. Such code grows, get copied into off-by-one, and gradually gets customized. By code-generating it now, you'll make maintenance easier in the future.
• You want to document the rules. As codeGen essentially acts as documentation, this will give you a place to clearly define all those boundary cases.
• The code is already easy to generate. If the code is already prepared to be generated, might as well go ahead and migrate it.

Preparing your code to be code-generated

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/preparing_your_code_to_be_codegenerated.htm]

Sometimes you're not sure if something should be code-generated. If you do end up code-generating it in the future, there are several guidelines you can follow to make your life easier:

• Physically place the code in separate files. One of the hardest things to do with code-gen is to merge generated and custom code. By isolated the potential code in its own file, you'll spare yourself this pain.
• Standardize and simplify your code. For example, if you prefix all variables with Hungarian notation, your code-generator would need to do extra work to determine what that prefix is.
• Refactor as much as possible first. The less unique code you have, the easier it will be. there's also a good balance between code-generation and refactoring.
• Document the rules. If you're writing code based off a set of rules, document those rules - they'll come in handy as you try to generate the edge cases.

 

R6034 - An application has made an attempt to load the C runtime library incorrectly

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/r6034__an_application_has_made_an_attempt_to_load_the_c_run.htm]

A coworker recently got this error when trying to open a web application project within Visual Studio 2008:

Runtime Error!

Program: C:\Prog...

R6034

An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.

Note that in this case, (1) Visual Studio opened just fine, (2) the problem was in merely loading a web project, and (3) nothing was even being compiled yet.

It turned out the problem was likely from a corrupt uninstall of the .Net 3.5 SP1. By re-installing the SP, things began to work again.

NOTE: .Net 3.5 SP1 has a potential error with the web dlls, so you may need to make some tweaks to the GAC.

Silverlight Tour in Chicago

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/silverlight_tour_in_chicago.htm]

For those interested in Silverlight, there is a Silverlight tour that will be offering classes in Chicago. You can find more details at: http://silverlight-tour.com/. I'm told that this is the first training that is teaching Silverlight 3. While this is not a free event, it may be well worth the cost if you're a Silverlight fan.

Hat tip from Shawn Wildermuth.

Is unit testing a second class citizen?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/is_unit_testing_a_second_class_citizen.htm]

Especially with the successful track record of unit tests, no project wants to be caught rejecting the notion of "unit testing your software". However, for many projects, unit testing seems like a second-class citizen. Sure, people speak the buzzwords, but they don't actually believe it, hence they diminish unit tests as some secondary thing unworthy of time or resources, as opposed to "real code".

1. Will developers actually spend time writing unit tests while they develop a feature (not just as an afterthought)?
2. Will developers (including architects) design their code such that it's conducive to unit testing?
3. Will a broken test get a manager's attention, or is it just some nuance to be worked around?
4. When a business logic bug is found, is there enough of an infrastructure such that you could write a unit test to catch it (the test initially fails because the code is broken, then passes once you fix the bug)?
5. Will developers invest mental energy in learning to write better tests, such as reading blogs or books on testing, or experimenting with better testing techniques?
6. Will developers write unit tests even when no-one's looking, or is it just some "tax" to appease an architect or manager?
7. Will management support the hardware for it, like having an external build server with the right software (while NUnit is free, MSTest still requires a VS license)?
8. Will a broken unit test cause the build to fail?
9. During code reviews, will other devs review your unit tests, similar to how a QA person reviews functionality?
10. Do your amount of unit tests increase as the rest of the project grows?
11. Is the team concerned with code coverage?

You know management is going to ask for it

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/you_know_management_is_going_to_ask_for_it.htm]

Time is precious, so it's natural to always be on the lookout for short-cuts. But certain short-cuts end up being anything but short, costing you far more later than if they had just been done up front. In other words, even if management promises "don't waste your time on it", you know that they'll come back to you and ask for it:

• Cross-browser web applications - they say "just worry about IE for now", only to want FireFox a year later.
• Refactoring your navigation - they're going to want a page referenced from multiple places.
• Scalability - They might say "just get it done now", but they'll want it to scale up.
• Changing any environmental value - they may let you assume some environmental value, like the hard-drive disk volume or some url, but you know it's going to eventually change.
• Turning static data into dynamic data - any hard-coded data (like entering a customer service phone number) is going to change.
• Changing relationships from one to many - you want to pass in a single scalar, but really the business rules require an array (or a one-to-many database relationship).
• Allowing client customizations and overrides -
• Some way of doing online help documentation -

I lose track of how many changes like these happen. It's best to just always be prepared for it. Even if the manager (or client) signs of on some waterfall doc, it won't matter, because without the change they'll feel "cheated" and resent the developer.

The kicker is that with the right starting framework, tools, and code-smell, many some of these changes take roughly the same amount of time to "do right" as to hack them (like cross-browser JS or using app.config values for literals like paths), especially when it comes to total cost of ownership.

BOOK: Framework Design Guidelines

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_framework_design_guidelines.htm]

A while back I finished reading Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. It's been ranked well on Amazon, and I can see why. Besides the general guidance one expects from a book like this, it had two other things that I really liked: (1) all the commentary from top .Net Architects, and (2) it provided a behind-the-scenes history of how the .Net Framework and Base Class Library came to be. Especially for practitioners who have made .Net their life (like myself), these are good things to see. I remember back when I started with .Net 1.0 in 2002, and how it's progressed from there to 1.1 and 2.0 and 3.0 and 3.5 and now "3.6" (i.e. .Net 3.5 SP1), so the book has been a good stroll down memory lane.

I'm impressed by the sheer volume of practical examples - this book is not some ivory tower theory pamphlet, but rather written from the first-hand experiences in the trenches.

I think the book got off to a strong start with "What makes a framework easy to experiment with?" As the brunt of it is a giant list of "do's" and "don'ts", it can get a little tedious at time, but it's still a very good read. I think reading an authoritative book like this also gives you a little more confidence that there's not something obvious that you're missing, as well as subtly increasing your code-smell.