I have just been proven wrong, and this happens so infrequently that it warrants its own blog post (kidding!)
In a number of the installments of the Summer of NHibernate screencast series, I have repeatedly made the assertion that when one makes a change to an embedded resource in their Visual Studio project, the developer has to explicitly select REBUILD for that project because a change to an embedded resource in a project isn’t considered by Visual Studio to be a change that will ‘trip’ the BUILD action into considering that the project needs to be recompiled.
In the context of NHibernate, this issue relates to managing changes to the .hbm.xml mapping files that my screencasts have recommended be managed as embedded resources in one’s Data Transfer Object project. When working in the screencasts on tweaking the contents of these mapping files, I have repeatedly advised that the developer needs to take caution to remember to explicitly call REBUILD on the project that contains the mapping files because otherwise Visual Studio will not recompile the assembly for that project and the mapping file embedded resources will not be updated in the assembly.
THIS IS WRONG (sort of!)
An astute viewer sent me a comment that suggested that in at least one of the screencasts I failed to REBUILD this project and yet the updated mapping file changes were still properly updated in the assembly — suggesting that an explicit REBUILD was not required. I was skeptical of this, but promised to investigate. I have done so now and my investigation has turned up the following: Visual Studio 2008 does indeed now ‘properly’ consider a change to an embedded resource item as a condition for which it will BUILD the project.
This is wonderfully helpful and yet entirely stealthy — I can find no documentation, announcement, or change-log for VS 2008 that suggests this is a change from past behavior and yet it clearly is such. Visual Studio 2005 definitely still evidences the behavior that I was indicating where you must explicitly invoke REBUILD on the project to get changes to embedded resources to be reflected in your compiled assembly.
I can see how this wouldn’t really make headlines for MS in selling updates to VS 2008 (e.g., "Rush out and get your Update to Visual Studio 2008 and reap the rewards of auto-building when embedded resources have changed!" is hardly as effective a selling point as "now with embedded designers for WPF!") but I would have liked to have heard at least something about this somewhere!
Mea Culpa
In any case, I clearly missed this and kept my old VS 2005-style of working without ever considering that it might have been ‘fixed’ in VS 2008. Now I wonder how many other ‘habitual work-arounds’ I have in my arsenal are no longer needed either….
Hmm, glad someone else noticed that. I was convinced you didn’t rebuild that one time, and yet managed to get a working test, while i was already chuckling about how it would fail 🙂
Great series, i’m learning a lot from you and i thank you for the time and effort you put in this.
Alain.
Better to tell people to do it when it’s not needed, than to not tell people to do it when it is needed. After all, not all of your fans are VS’08 users.
I also want to express my gratitude for this great series. Not only is it a great intro to NHibernate, but it shows great software-development practices overall, and is a great model for others in the industry to follow, too. What awesome resources would there be if even a few more companies took a little extra time and put their training videos online too! Thanks so much!
@Andrew:
Good points — an EXTRA build isn’t going to hurt anyone for those that ARE using VS2008 but I DID want to point out to VS2008 users that this isn’t any longer required.
I will likely mention this at the beginning of the next video so that viewers that aren’t visiting my blog are still made aware of the differnt behaviors between the two IDE revs.
@Steve
Ah, so I wasn’t imagining it after all! 🙂
(thanks for following this one up for me)
Actually, this is also the behavior of VS 05.
The bug you are talking about was in VS 03 🙂
@Ayende:
Corrected again! WOW. I’m wrong in my post about my being wrong…is that recursion ??? 🙂
Now that’s a LONG time to have been carrying that ‘behavioral work-around’ in my bag-of-tricks. I guess that’s what you get when someone introduces a non-breraking, *fixing* change to an updated software release — you may not notice for quite some time that what was once broken is now fixed~!
Thanks for the clarity, as always.
Steve,
Did I say how much I appreciate these webcasts? I didn’t. That might be because I’ve been spending so much time evangelizing them to the people I work with.
I’ve learned a LOT from them.
You’re now on my Hero list.
MArk B.
BTW: I noticed the compiling AND the bad logic in that one test. I’m so proud of myself.
MArk B.
It’s the little things.