VS 2010 Database Projects Post Deployment Scripts not Executing

Today I have been dealing with a really frustrating problem when working the DB Projects in Visual Studio 2010.

One really great feature is the pre/post-deployment scripts that you can execute on each deploy for things like static or reference data.  Or in some cases some test data as well not run by a data generation plan.

My issue was whenever I'd click deploy, the DB would be recreated, my tables I updated were created as expected, but it would not execute the post deployment file.  After some help from a co-worker, he diagnosed and found the problem was with the Build Action property on the file itself.

To correct, select the Script.PostDeployment.sql file in the Solution Explorer.  Click F4 if necessary to display the property grid.  Click Build Action, choose PostDeploy.  Deploy away.

Hope this saves you a few frustrating hours.

One note, you may only have 1 post deployment file in your project, use SQLCMD :r syntax to run all the scripts you want to execute post deploy.

The greatest ViewState attribute to ever exist - Dynamic Controls just became easy

Recently at work, we were dealing with the ol' dynamic controls and ViewState problem. You know.. This one.

Failed to load viewstate.
The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request.

I've seen a lot of *elegant* solutions on how to solve this. All these examples proving it out what have you.

I can't beleive Microsoft would hose us over with such a thing!!!

Well, they didn't... Hello ViewStateModeById !

How does it work?  Reflect it, what you'll find is that it simply iterates through the control tree by name instead of the index version which iterates through the tree (for each INamingContainer ) and then takes a value at the same index position in the ViewState statebag.  This is highly efficient, and with the way web forms are typically used, it works.

The counter to the ViewStateByModeId is performance.  But look at most of the dynamic control ViewState problem solving methods out there.  You'll find a great many simply use the same method to find the name of the control in the control tree.  If you consider the general computing power of modern servers, the performance impact is negligible.  There are edge cases where you have massive control trees, but if so, it might be a good idea to look at your overall page structure and other optimizations.  Don't blame it on the ViewState.

Not only that, they implemented it as both a property on Control and an Attribute.  Remember that Page is inherited from Control, so OnInit, just set the property first, then add your controls here not in Page_Load.  The lifecycle has already passed the LoadViewState event. 

There is one gotcha.  It does not quite work correctly on radio groups, so you have to request the value from the Form in order to set it, get values.  

One line of code that has saved me more hours and that much frustration than is fathomable.  Hope you get the same. Time to cross post the hell out of this.

You're welcome ;)