Contents tagged with Versioning and Compatibility
-
Fed Up With Project Versions
It's kind of a pain in the butt to have to compile stuff to two different versions of the Framework. I haven't dived into Whidbey too much, but I sure hope MSBuild lets you define which version of the Framework you want to target (I'm pretty sure it does, but I could be wrong). At any rate, I have to maintain two versions of my projects and solutions. It's kind of a pain to go through and edit my project and solution files after I'm finished with the 2003 version so I can compile in 2002, so I spent most of the night coming up with this solution: The VS.NET Version Commander.
-
Building a Better Server Control Experience, Part 2
Details matter. Especially in building solutions people pay for. You've heard of the term WYSIWYG? Well why isn't the term YGWYPF more prevalent? It stands for You Get What You Pay For, and it's more true in today's economy than most people realize. So where are the little details in server controls? What are the mundane, time-consuming details that set apart a proof-of-concept from a true solution? Over the next few posts, I'll address them.
-
Basic .NET: Framework Compatibility Issues
My fifth article for Builder.com is now online. This is the first of a three-part series on .NET Compatibility. These articles stemmed from my “No-Brainer Compatibility” rant, and will hopefully provide a crystal clear explanation as to how to tackle these issues in an intelligent manner. Coming up in two weeks is part two: Developing Components: Assembly Identification. You won't want to miss it.
-
"No-Brainer Compatibility" Explained
For several weeks now, I've been talking about various issues in regards to component versioning and Framework compatibility. A few months ago, I got so frustrated by the issues that were raised, that I said I was going to start a task force to solve the problem. This task force was informal and basically consisted of Paul Alexander (XHEO) and I (Interscape Technologies). Over the past 6 months, I have really enjoyed working with Paul, and I am constantly amazed at the work he achieves. Together, we've been able to make some headway in the industry as a whole, and we have several extremely exciting things coming up in the future.
-
.NET Framework Graphics - "No Brainer Compatibility"
Paul Alexander was kind enough to put together a series of really slick graphics elements that were designed to denote which version of the .NET Framework a particular component was compiled to. This is ideal in situations where you either a) only have one compiled version of your app, or b) have separate installers for each version.
-
Versioning Redux
Frans says:
That's all fine what MS thinks I should do but what I think MS should do is make their IDE able to work with older CLR's so people can choose a new IDE while writing a control for 1.0 or 1.1. MS didn't even bother creating a config file for a library so a library can be made runnable on 1.0 with redirects.
I would have responded in my comments, but I wanted everyone to know this:
The guy I talked to at MS said that redirect policies in the web.config file apply to all subsequently loaded assemblies, including components. This means that your component should run if the user add binding redirects in the web.config. You can also use publisher policy files and register the same binding redirects in teh GAC, but that is much more of a pain.