Friday, August 28, 2009

All for that small Drop Down Box – Part 3

I wrote couple of posts describing how Web MultiTargeting (Web MT) works in VS 2010… You can find those posts at:

Today  I hope to cover few other things related to MultiTargeting that the team focused on during VS 2010 and ASP.NET 4 cycle…

Silverlight MultiTargeting

VS 2010 will allow you to develop Silverlight (SL) projects seamlessly…  SL has got its own runtime versions like SL 2.0/3.0 and eventually there will be SL 4.0 too…  SL development has been possible with VS 2008 where you might have your Web Projects using SL 2.0 or 3.0 and now when VS 2010 comes out is is obvious that developers will expect smooth migration and upgrade for their VS 2008 SL projects into VS 2010…

So in VS 2010 there will be functionality available to upgrade your SL projects to SL 3.0… As SL has different versions it becomes important for VS 2010 to support MultiTargeting between different SL versions… Do note that these version are completely independent of .NET FX versions…

We have talked about Web Projects supporting .NET 2.0/3.0/3.5 as well as .NET 4… In addition to this it is now important for each of these Web Project to support different versions of SL… Thus when you create a new SL project there will be a drop down in the new project creation wizard which allows you to choose what version of SL do you want to target as shown below:

Silverlight New Project

On selecting Silverlight Application when you click “OK” then the below wizard will show up which will allow you to target the available Silverlight versions in your project…

Silverlight MT

SL MT also uses the Reference assemblies infrastructure that we discussed during Part –1 of this post…  You can find that SL also has its own set of “Reference Assemblies” as shown below:

SL Reference Assemblies

This actually brings up an interesting point to note that Reference Assemblies infrastructure is pretty extensible and can be used for Frameworks which are technically outside of .NET Framework too…

ASP.NET MVC

As you know ASP.NET MVC 1.0 was released on top of VS 2008… Then eventually the support for VS 2010 was also provided…  VS 2010 will fully support ASP.NET MVC just like it supports Web Application Projects or Web Site Projects… There will be upgrade options available from VS 2008 MVC projects to VS 2010 MVC Projects… 

MVC projects can MultiTarget based on project references i.e. if you have reference to MVC 1.0 your intellisense will work for 1.0 and if you have reference to MVC 2.0 your intellisense will work for 2.0…  If your hoster does not support ASP.NET MVC just yet you can just select the reference to MVC assemblies and in the properties mark “CopyLocal” to True which will copy the MVC assemblies into your BIN which you can just simply deploy to the server along with your project (as shown below)…

CopyLocal

Multiple Frameworks in same Solution

If you have read Web MultiTargeting posts (Part 1Part 2) you already know by now that there is a lot happening with respect to toolbox filtering, property grid filtering, context sensitive markup intellisense, JavaScript intellisense, C#/VB intellisense,  IIS App Pool management, web.config etc… 

If someone has a big solution with several web projects, few class libraries, few web services etc, it is very likely that they will not update all of their project at the same time to .NET 4… So VS 2010 needs to make sure that things don’t break even if there were multiple projects in a single solution and all of them were targeting different .NET Framework Versions (with few Silverlight projects with multiple versions into the mix :-)) …

There were various stress scenarios which were tested and optimized for in this area… In fact we have something called as “Overall Goodness Factor (OGF)”… OGF is a subjective adhoc test which needs to be performed on a regular basis by various people across the the team to understand how the product is behaving…  As most of the folks in our teams are developers (even if their title don’t say so :-)) they do reasonable job in playing around with various real world projects… This particular OGF covering stress scenario was always hard to execute, coz every time we had to set up this complex project structure from ground up and play around with it to make sure VS 2010 is actually performing correctly… Btw, the OGF report is sent out pretty broadly across the division for features like MT so if  any team’s OGF was not “Good” it use to become the the center of everyone’s attraction across the division (not in a good way :-))… In short there was enough motivation provided to get things right!!

Making sure all Web Stack Features Work

As Web MT operates relatively in the lower layers of VS 2010 and ASP.NET 4 stack a small issue in MT surfaces as a big issue somewhere else… Although this is very much assumed and expected but the MT team had to specifically write Automation tests to ensure other features within the products like Dynamic Data, AJAX, Web Deployment, Build/Compilation, Debugging, WCF, Web Services etc etc continues to perform while targeting any .NET Framework version…

Most of the time we did not face a lot of issue in this area, but nevertheless something which is worth mentioning…:-)

Target Framework Moniker & Profiles

As we talked about earlier “Reference Assemblies” which are laid down on the disk at %Program Files%\Reference Assemblies folder are meta data only assemblies… By default there are Reference Assemblies folders created for Silverlight versions and .NET Framework versions (e.g. 2.0, 3.0. 3.5 & 4)… VS 2010 architecture runs using a concept called as “Target Framework Moniker” which describes where reference assemblies should be picked from the disk…  The target framework Moniker looks something like below:

".NETFramework,Version=v4.0,Profile=ServerCore"

  • Target Framework Identifier (“.NETFramework” in above example)
  • Target Framework Version (“Version=v4.0” in above example)
  • Profile Name (“ServerCore” in above example)

Based of this information VS 2010 will pick up “Reference Assemblies” which in turn will allow VS 2010 to control the behavior across the board in the IDE (i.e. on toolbox filtering, intellisense, property grid filtering etc etc)…

When Profile Name in the target framework Moniker is present then VS 2010 looks under the framework for the presence of the Profile definition (Think of “MT Profile” as a SUBSET of the full .NET framework)

Profile Folder

When Profile Name in target framework Moniker is missing then the full frameworks are picked up… i.e. “.NETFramework,Version=v4.0” will pick up reference assemblies for the full .NET 4 Framework… 

Profiles are interesting coz in the future there might be platforms and servers which do not need full .NET Framework but only subset of it… VS 2010 can ensure that projects developed using a specific Profile will not land up accidentally consuming the larger surface area of .NET framework which might be absent on the destination… Eventually Mobile development can have its own profile and so can Windows Client development have its own… Anyways, the key point is that “Profiles” are a reusable way to provide MultiTargeting support with Visual Studio and will be expressed via the “target framework moniker”…

You might be wondering where is this target Framework Moniker physically visible… Well the answer is complicated but what is important to note is that starting .NET 4 ASP.NET web.config  schema will support a special attribute called targetFramework=”4.0” as shown below:

TargetFrameworkMoniker

Following things are worth noting about this attribute:

  • The attribute resides on the compilation node of the system.web attribute of the web.config…
  • This attribute was introduced in ASP.NET 4 and it is not supported for .NET 2.0/3.0/3.5 webs (as they shipped before the concept of Reference Assemblies and Profiles was introduced)… i.e. do not try to code something like “targetFramework=v3.5” in VS 2010  it will not work :-)
  • “targetFramework” attribute is just a short form of “targetFrameworkMoniker”…
  • “targetFrameworkMoniker” was the attribute which was earlier used in VS 2010 Beta1 but in final VS 2010 release it will be renamed to “targetFramework”…
  • targetFramework=”4.0” is same as targetFramework=.NETFramework,Version=v4.0”
  • If there was a profile then that could be added to targetFramework too e.g. targetFramework=”.NETFramework,Version=v4.0,Profile=ServerCore" (btw, Profile=ServerCore" is just a made up name by me, it does not exist :-))
  • Post VS 2010 Beta1, targetFramework will not be a required attribute at runtime for ASP.NET 4… But, it is required for VS 2010 to support correct MT behavior within IDE so I strongly encourage you to not delete that attribute from your web.config file… Its, just a little attribute it means no harm :-)
  • As targetFramework attribute is optional at runtime, if it was missing from web.config and the web was deployed under .NET 2.0 App Pool in IIS then ASP.NET will assume the web to be 2.0 Web… If the web was deployed on .NET 4.0 App Pool in IIS then ASP.NET will assume that the web is .NET 4 web… 
  • targetFrameworkMoniker, which was  the VS 2010 Beta1  equivalent of targetFramework attribute was a required attribute  i.e. if that was absent you would get an error as below:

“The application domain or application pool is currently running version 4.0 or later of the .NET Framework. This can occur if IIS settings have been set to 4.0 or later for this Web application, or if you are using version 4.0 or later of the ASP.NET Web Development Server. The <compilation> element in the Web.config file for this Web application does not contain the required 'targetFrameworkMoniker' attribute for this version of the .NET Framework (for example, '<compilation targetFrameworkMoniker=".NETFramework,Version=v4.0">'). Update the Web.config file with this attribute, or configure the Web application to use a different version of the .NET Framework.”

The solution for the above error in VS 2010 BETA 1 is to add below attribute under compilation node of the web.config file

targetFrameworkMoniker=.NETFramework,Version=v4.0”

Anyways, I guess now you know a lot more about a single attribute within web.config than you would ideally like to, so let’s move on :-)

Retargeting between Framework Versions

I intentionally kept this piece towards the end coz now you know a whole gamut of things that happen around Web MT within Visual Studio for a single project… The nice part is that VS 2010 will allow you to simply go to your project properties and use that retargeting drop down box shown below to flip your Framework version between 2.0, 3.0, 3.5, 4 or any of the Profiles that might be installed on your box… And as soon as you retarget IDE will frantically start doing a bunch of things behind the scenes and within no time will reload your project and get you all set on new Framework of your choice…

image

If you choose to down target your project from say .NET 4 to .NET  3.5 you will get a bunch of errors when you build, the primary reason for that is that VS 2010 cannot simply wipe out source code from your code files, it does not really know what code you wrote and tweaked painstakingly and suddenly loosing it all might be scary… But anyways, the chances of people moving from .NET 4 to 3.5 are very few so most people do not ever experience the errors… Even if you see retargeting errors most of the time the solution is all about deleting some new 4.0 specific code which is pretty easy to do…

Anyways, in the image above you will also see a tons of extra frameworks, we have not yet made progress beyond 4.0, so most of them are not real… :-) They are all the test profiles and frameworks that MT team created painstakingly to make sure MT really works in whatever difficult situation we will throw at it…  So, when VS 2010 ships all the test frameworks will be gone and all you will see are few Frameworks is that small Drop Down Box…. :-)

-Vishal

The remaining posts in the Web MultiTargeting Series are:

Tuesday, August 25, 2009

All for that small Drop Down Box – Part 2

Web MultiTargeting (Web MT) for VS 2010 has been a great journey of fine technology and a tons of learning for me in person, I am sure everyone in the team feels very similar (although some may add “+ lot of pain” into the mix :-))…  Yesterday, I published some of the details around what Web MT offers web developers in VS 2010… You can read it at:

All for that small Drop Down Box – Part 1

I covered approx 10 different features of MultiTargeting in the previous post, today I am going to time box myself to a couple of hours to write as much as I can and then see if we need Part –3 of this series in few more days or not… :-)

Anyways, let us get started!!

Filtering Markup Intellisense

One of the essential benefits of working within IDE like Visual Studio is that you get your code colorized correctly and intellisense keeps showing up as and when you need it…  Before working on many of these feature areas I often use to take things like keywords getting colorized and intellisense showing up etc pretty much for granted, now I don’t, now I appreciate that ultimately everything is a text pad before it becomes as fancy as VS 2010 code editor is… :-)

The MT team did a reasonable amount of work to make sure that when you go about typing <asp: in HTML editor of VS 2010 and you start getting intellisense as below:

markup intellisense

then that is actually customized to the correct ASP.NET version… Imagine if folks got <asp:ListBox in .NET 2.0 project (where ListBox control is not supported) and they started using the ListBox only to find out when the web project is deployed it will not work…  Well, VS 2010 will not show you <asp:List Box in .NET 2.0 project but in order to do that there was work done to filter out the mark up from intellisense which does not apply in a particular framework… After we got the filtering working then the team was assigned to do some more work to make sure that the design was refined in a way that it did not adversely impact performance…

Correct JavaScript Intellisense

You must have already heard that VS 2010 gives great JavaScript intellisense support… In fact in VS 2010 there was a lot of work in this area (out side of MT work) to ensure that you get intellisense everywhere, hopefully I will write about that also in a different post but whether or not I do I am sure you will start noticing the difference in JavaScript intellisense in VS 2010 over VS 2008…

Anyways, for now what is interesting to know is that for Microsoft AJAX the JavaScript files are embedded inside the assemblies like System.Web.Extensions etc…  The AJAX support has only been growing in every .NET framework release and it is one of the reasons why people move from .NET 2.0 to 3.5 and will hopefully move to .NET 4 too… 

You might recollect the reference assemblies discussion from my Part 1 post and that reference assemblies are meta data only assemblies… You might also recollect that VS 2010 process loads only .NET 4 and then reference assemblies are used to mask .NET 4 features in lower level targets like .NET 2.0/3.0 and 3.5… 

Now the AJAX JavaScript files are embedded inside assemblies and they actually differ from framework to framework…  If VS 2010 would use the embedded JavaScript files from .NET 4 assemblies all the time then .NET 2.0/3.5 projects would land up consuming some JavaScript functions which may not be available in that framework…  Due to such scenarios the Reference assemblies actually always contain embedded resources (even though they do not actually contain the source code implementations)… Web MT team worked on getting these embedded resources from the correct reference assemblies and feeding to the JavaScript intellisense engine to ensure that you get correct AJAX intellisense when you are using Microsoft AJAX feature sets…  It was kind of cool to see even JavaScript intellisense get target aware, I hope folks who use a lot of Microsoft AJAX will be able to appreciate this :-)

Special support for AJAX Control Toolkit (ACT)

It is funny that we land up calling AJAX Control Toolkit as “ACT”, I guess not many web developers using and contributing to ACT don’t do so!!  Anyways, ACT 1.0 was an out of band release (i.e. it did not ship as part of .NET 2.0) and offered various controls and extenders which are used by many many web developers…  Eventually ACT 3.5 and now community previews of recent ACT release are becoming available…  When you download and use ACT then you get controls and extenders in your toolbox and your web controls get options to add or remove extenders (e.g. A TextBox control can have a ColorPicker extender)… When all this things come together in VS 2010 there are a lot of possibilities like what if you have .NET 2.o project what kind of ACT should be made available, what if you have ACT 1.0 as well as ACT 3.5  on your box how should VS 2010 react to it, what should be allowed and what should be prevented via errors and intellisense so that web developers do not land up getting their webs into a bad state… ACT in itself with all its combinations keeps several members of our QA team busy for extended period of time… Their goal is  that things should just work and web developers should remain blissfully unaware of the complexity behind the scene… 

Actually the entire MultiTargeting feature in a way is like that “If you as a developer never realized MTs existence throughout your project lifespan--> from creation, to editing to deployment in production, to end of maintenance life then it is “mission accomplished” for us:-)”…  It feels like working in the entertainment industry, making movies everyday and contributing in the category of work which is pivotal but does not have an Oscar category associated with it!!  As long as our movie is loved by the people watching it we will be happy and satisfied, so in short the ask from you is “Love VS 2010 and .NET 4”  it is indeed great!!

Support for 3rd party controls

Ensuring that 3rd party controls from likes of Infragistics and Dundas work seamlessly across framework versions (based on how they are designed) was also important… Some people want to be able to not keep buying same control over and over again after upgrading their framework version (sounds familiar :-))…  There is a reasonable amount of work done in verifying controls from many of our partners and also working with many control vendors to provide them with the guidance on how to work within VS 2010 to make sure things continue to work find when people migrate their projects into VS 2010…  The central MT team across the division worked together to come up with a guidance document for control vendors to integrate into VS 2010, even this simple blog post series is long enough so I will leave to you to imagine how much information must be poured into that document which will be used by various companies to build controls which will work within VS 2010…  You will be surprised on how versioning, licensing and naming is done by various partners… Ensuring that nothing of this broke in VS 2010 was not easy…:-)

ASP.NET Compilation System

With .NET 4 running in VS 2010 process the ASP.NET Compilation System used is also .NET 4… Before we talk more about this let me tell you what ASP.NET Compilation System does – it is the system which actually takes the web pages, parses the various ASP.NET related syntax present inside the HTML e.g. <asp:GridView etc and converts that into code… It also pulls out all of the inline C# or VB code out of your web page and calls the correct C#/VB compiler on it… This is the core ASP.NET Compiler which runs inside of Visual Studio…

Now imagine that the ASP.NET Compiler within VS 2010 was required to be made target aware… What I mean by that is when you are targeting .NET 2.0 and you have .NET 4.0 syntax in your web then the compiler needs to throw an error which shows up in your VS 2010 error list which you can then double click and you are taken to the line on which there was an error…  This actually is the same kind of error reporting mechanism that happens even when there is a typo in source code… In essence ASP.NET 4 compiler needs to get into the “correct framework mode” to provide the accurate error messaging and to avoid any type bleeding from happening…

There are also MT implications on C# and VB compilers which I will possibly cover in a separate post… In any case trust me that making compilation system target aware is a significant endeavor…

IIS Application Pool Mappings

As you know we have Visual Studio Development Server (aka Cassini) that is used to debug/run your project within VS without needing IIS…  I talked a little bit about this in my previous post… The other possibility for running and debugging your app is by using IIS on your local box itself…

VS allows you to create a WAP or a Web Site which uses IIS instead of Cassini… Even here MT needs to intervene; if you are creating a .NET 2.0 IIS Web then VS 2010 needs to go access IIS and create Virtual Directories, IIS Apps and map them to the correct App Pools running in correct target frameworks… Simply put VS 2010 needs to put .NET 2.0 project in .NET 2.0 App Pool and .NET 4 project in .NET 4 App Pool…  I wish it was just limited to this but there are instances when correct App Pools are not available and then VS 2010 needs to go and create them for that framework… Sometime the project is mapped to use .NET 2.0 App Pool and now it is being upgraded to .NET 4… In this scenario VS needs to go and change the IIS App to use the correct App Pool too…

VS 2010 actually uses IIS 6 Metabase APIs to make these changes and even when you are using IIS 7.0 or 7.5 VS 2010 continues to use the same Metabase APIs and hence if you are using IIS as your development server with VS 2010 with Vista/Win7 you will need to have IIS 6 Metabase Compatibility Layer turned on in Control Panel –> Programs–> Turn Windows Features On/Off  as shown below:

metabse compatibility

It is not only when VS 2010 flips/flops Virtual Directory App Pools when this compatibility layer is used… It is also used when IIS App is created for the first time, in short it is used every time you use IIS based web project within VS 2010…

In all honesty, in VS we could write code to get rid of the IIS 6 Metabase compatibility dependency and instead start using IIS 7 configuration system API but there was a lot work needed to do that we could never get to completely finishing it on time… :-( I totally understand that it is going to be an inconvenience to have the compatibility layer enabled and I apologize for the same but I hope that you will recognize the fact that we do have the intent to finish the work but just from cost and schedule standpoint we could not fit this work into VS 2010…

Anyways, I have reached at the end of my stipulated couple of hours of time to write this post… I assumed that if I give myself couple of hours to write then the content will be at reasonable reading length without making everyone bored, it will also ensure that I do not start writing gibberish :-)

I certainly have more inner workings to tell you about Web MT but I guess that the content is interesting enough to deserve “All for that small Drop Down Box - Part 3”…!!

So until then please do feel free to let me know if any of this is any good to anyone reading :-)

-Vishal

The remaining posts in the Web MultiTargeting Series are:

Monday, August 24, 2009

All for that small Drop Down Box – Part 1

Multi Targeting in Visual Studio 2010 is surprisingly a big feature area… It falls under the category of what we called as a “Divisional Initiatives” which spans across nearly all of Visual Studio and .NET Framework teams… Even engineers from outside of VS and .NET teams contributed significantly on the project... With this series of blog posts I am going to merely focus on MultiTargeting (MT) for Web Developers in Visual Studio 2010 and ASP.NET 4…

First of all let me call out by saying that in VS 2008 there was only one version of CLR i.e. CLR 2.0… Various framework versions i.e. .NET 2.0, .NET 3.0 and .NET 3.5 were only changes to the framework assemblies which still ran on the same CLR 2.0…  With .NET 4 this equation changes coz .NET 4 runs on CLR 4…  VS 2010 now needs to support .NET 2.0, .NET 3.0, .NET 3.5 as well as .NET 4 Applications; this implies that now we are about to cross into different CLRs for Applications targeting different Framework Versions… Solving this issue is in part what VS 2010 MT is all about… Solving this problem for various ASP.NET Web projects is what Web MT is all about…

As VS 2010 itself loads CLR 4, trying to create, edit, debug, deploy applications with VS 2010 running on CLR 2 would mean loading CLR 2 inside CLR 4…  That without going into detail is a technical nightmare… To overcome this VS 2010 loads only CLR 4 and .NET 4 in its process and for applications targeting .NET 2.0, 3.0 or 3.5 VS 2010 makes .NET 4 emulate .NET 2.0/3.0 or 3.5.

So how does the emulation inside VS 2010 really happen?

With VS 2010 there is a new concept called as “Reference Assemblies”… “Reference Assemblies” simply put are meta data assemblies which represent each framework… These assemblies do not contain the complete implementation of the framework they just allow VS 2010 to decipher what classes, methods, properties, resources etc are really present in each .NET Framework version… You can find these “Reference Assemblies” in %Program Files%\Reference Assemblies folder…. There is more to the process of creating “Reference Assemblies” and registering them etc but for now I will not get into those details…

As I mentioned earlier inside VS 2010 process only CLR 4 and .NET Framework 4 is loaded… If you create a .NET 2.0 project, VS 2010 will use the .NET 2.0 Reference assemblies to ensure that your project behaves like a .NET 2.0 app… Although, all the time when you are editing your .NET 2.0 code, designing your web pages, authoring controls, debugging etc you are actually using .NET 4 but VS 2010 is masking off all the .NET 4 features based on the directions provided by .NET 2.0 Reference Assemblies… Now when you build your projects VS 2010 cannot use .NET 4 and CLR 4 to create the output assemblies coz if VS 2010 would do that then you would not be able to run your project on a box which only has only .NET 2.0 (i.e. not CLR 4/.NET 4)…  Hence, when it comes to building the assemblies VS 2010 launches the correct compilers out of process and generates the correct assemblies for your project…

Now with this high level understanding let me mention that as I write this article I am thinking that I have been lucky to have worked with great engineers across the company to make the VS 2010 MT experience the way it is today and additionally I feel lucky that people whom we build all this stuff for (ie .NET developers world wide) can actually understand what goes into development of such a system as Visual Studio and .NET Framework… Anyways, let us get into the meat of what all does all this crazy MT stuff buys web developers at the end of the day (APART FROM THAT SMALL DROP DOWN BOX that you see…  :-)

small drop down box

Migrating pre-VS 2010 (starting from VS 2003) web projects to VS 2010 – One of the feature areas of Web MT is migration of apps created using previous version of VS to VS 2010.  VS 2010 allows migration from VS 2003, VS 2005 as well as VS 2008…  This entails modifying the solution files (.sln) and project files (.csproj/.vbproj) of your Web Projects to make them complaint with VS 2010 format.

Have you wondered why do we need to do that??  As you might already know project and build systems within VS work using MSBuild… There are target files and task dlls which are installed as part of VS 2010 in specific directories… These directories need to be side by side with VS 2008/VS 2005 directories to ensure that you can run VS 2008 and VS 2005 on the same box and uninstalling of any of the IDEs does not break the other versions… Anyways, there are references to various target files inside the solution and project which need to be updated to be point to the correct directories of VS 2010… Apart from that there is also changes to IDE version etc which is embedded inside these files which are used by VS, all that stuff needs to be updated…

When you open VS 2003/2005 or 2008 projects in VS 2010, VS will automatically do this migration for you.

People always bring up the discussion where they would like few developers in their team try out VS 2010 and remaining stay with VS 2003/2005 or 2008.  They typically want to try out the VS 2010 release in a limited way and once the few folks trying the product give a green light they would move the entire team to VS 2010…  Doing this is of course possible but an additional ask which comes with that is “Can we have some developers use VS 2010 while others use VS 2008 for the same project/solution file in a common source control?”; unfortunately the answer to that is No…  The process of having the same project being operable in various versions of VS is what we call as “Round-Tripping”… We really did want to include this feature for VS 2010 but unfortunately could not due to the existing complexity of MT (as discussed above, below and everywhere in this post :-)) + limited time to get everything right… !!  Well, what is important is that we will make everyone in your project team move to VS 2010 easy enough that you can have the entire team bet on it at the same time…!!  Let us see how -

Upgrading pre- .NET 4 web projects to .NET 4  - VS 2010 will also allow you to upgrade your .NET Framework version from .NET 2.0, 3.0 or 3.5 to .NET 4…  This now enters the realm of making changes which impact your code… That is the reason VS 2010 allows you to either stay with your existing Framework version or upgrade the Framework version to .NET 4… There are tons of cool new ASP.NET 4 features, I encourage you to read the whitepaper on ASP.NET 4 and VS 2010 to learn more… -

Creating .NET 2.0, 3.0, 3.5 as well as .NET 4 projects – This is drop down box  which I am referring to in the title of this article… :-)  It will manifest itself again but what is important to note is that when you try to use File –> New –> Project or File –> New –> Web Site (as shown below), you will get a choice to choose the Framework version of your choice for the new project…

new project framework dropdown

Some folks will still have their web servers set up only for .NET 3.5 and in that case they can choose the corresponding framework version from the drop down…  As soon as the framework version is chosen in you will notice that the project templates will get filtered correctly…  When any of the project templates (or item templates) are authored we now have a concept of embedding the “Min Framework Version” and “Max Framework Version” in them…  This allows VS 2010 to determine which templates to show and hide when you are choosing a particular Framework.  It also ensures that we do not need to have multiple copies of the same template within VS saving time and size during VS 2010 install…

Filtering Item Templates for Framework Version – Similar to the project templates discussion above are the details for the Item templates…  When you go ahead and try to right click on your project and Add—> New Item, similar filtering happens… For e.g. you do not see “ADO.NET Entity Data Model” item template if you right click on a .NET 2.0 project

image 

Item template filtering works similar to project template filtering… Also it is worth noting that there can always be custom code which can be run during “Project creation” or “adding Item Template” which allows VS 2010 to do special things with the template per .NET framework version…  A good example of this is the web.config file template which needs to generate different web.config file based on the .NET framework version…  So if you crack open a item template you might see some conditional framework based logic in there… :-)

ToolBox Filtering – As you are about to design your page or user control you may tend to drag and drop controls from toolbox… At this time VS 2010 needs to make sure that you see only the controls that your .NET version allows…  If you remember I mentioned earlier that VS 2010 is always running .NET 4…  If the toolbox showed all the controls associated with .NET 4 all the time then you might see unwanted controls when you are targeting .NET 2.0 and potentially may have errors in production if you used .NET 4 controls in .NET 2.0 projects… To avoid this from happening VS 2010 uses “Reference Assemblies” and the entire architecture surrounding them to identify what controls need to be shown in the toolbox…

At this time VS 2010 also gathers what the tooltip for the controls and shows them correctly to you so that you know what type of control are you using…

toolbox version tooltip

Additionally what is interesting to note is that the toolbox meta data population also happens for 3rd party controls and hence even if you were using Infragistics or Dundas control their metadata will also get correctly reflected in the Toolbox i.e. their framework dependency chain will be walked and correct Framework dependency will be verified…

As you can imagine there is a lot of work being done based on your framework version to go down to “Reference Assemblies” and find out what needs to be shown what does not and only after all that the toolbox gets populated correctly…

Property Grid Filtering – Now if you pause and ponder for a moment that it is only the .NET 4 control which is being used within VS all the time then you can possibly imagine that some controls may now have more properties in .NET 4 than what they use to have in the previous framework versions… For example let us take Login control in .NET 2.0 vs the same control in .NET 4… ClientIDMode did not use to exist in .NET 2.0 but does in .NET 4.

property grid filtering  In this case VS 2010 needs to make sure that those extra properties are not shown in the control property grid as shown above, coz if they do and someone accidentally sets them then they will appear as part of the .aspx/.ascx markup and will get deployed to the web server… As on the web server the app will be set to run in .NET 2.0 it will not recognize the ClientIDMode property and will throw an exception causing production failures. 

One additional goals of Web MT was to ensure that if at all there are any accidental mistakes then they are caught well early within VS rather than letting them propagate and have the application fail at runtime…

In fact I would say that it would be a cardinal sin for Web MT if VS 2010 design time allowed you to create an app which will fail after deployment and the teams over here have done whatever it takes to make sure that does not happen…

Switching C# & VB compilers for the correct Framework Versions – As I mentioned earlier based on the correct framework version the correct C# & VB compilers need to be invoked so that correct binaries can be produced for your projects… This also ensures that VS 2010 is able to catch errors in the C# & VB code based on the compiler features for the particular framework version… 

From compilation standpoint there are different things that happen for Web Application Projects (WAPs) as compared to Web Site Projects (WSPs) which I have explained in the article WAPs vs Web Sites and so there are is a interesting design on how the compiler switching happens in case of these different project systems… I will explain that in a future article but for now you can be rest assured that when you target .NET 3.5 VS 2010 will produce binaries which will run on .NET 3.5 and when you use .NET 4 VS 2010 will produce binaries which target .NET 4…:-)

Add Reference Dialog Filtering – When you try to add new references to your projects to any of the assemblies now you will notice that you will see the references associated with the correct framework version… Again this list is populated by querying reference assemblies similar to what toolbox and property grid filtering did…

In Add Reference dialog box again the validation is done against your project and you are shown only the references which are legit to be added to your project based on its .NET Framework version… 

You will also notice that the path of the Framework assemblies will be pointing to Reference Assemblies folder as shown below:

Add Reference

One of the big challenges that the team faced was trying to improve the performance as compared to VS 2008 while incorporating all these architectural changes around the meta data only assemblies…  The design of  reflecting upon the “Reference Assemblies” and then filtering out .NET 4 assemblies to finally populate the dialog boxes, tool boxes, property grids etc certainly is a lot more work as compared to simply looking at a fixed folder location that was being done in VS 2008…   I am really proud of our team who have spent countless amount of time in fine tuning the flow of these designs to ensure that performance is not adversely affected and hopefully in future builds of VS 2010 you will notice the perf improvements since Beta1 build…

Using the correct machine.config and root web.config

Many of you might be already aware that the web.config file that you see in your web project is actually part of a hierarchical config system…  There is machine.config as well as root web.config which resides in CONFIG folder under “%Windows%\Microsoft.NET\Frameworks\Vx” directory…   Actually an interesting piece to note is that for .NET 2.0, 3.0 and 3.5 the CLR version was always 2.0 and hence the machine.config and root web.config file was never changed since .NET 2.0, check out the “Config” folder for .NET 2.0, if you go to v3.0 or 3.5 you will not find any “Config” folder at all:

image

For .NET 4.0 you will have a similar folder and it will contain “machine.config” and “web.config” files… In essence .NET 4 is the first opportunity for ASP.NET to have a different root web.config and machine.config… Certainly that brings a huge set of advantages but increases the work we needed to do from Web MT standpoint. 

Now when you create .NET 2.0/3.0 or 3.5 project in VS 2010 then the machine.config and root web.config needs to be picked up from .NET 2.0 folder but if you create .NET 4 project then the machine.config and root web.config needs to be picked up from .NET 4 folder…  In nutshell when you start typing <appSettings> and so on in your web.config file do note that the schema intellisense that you get is also customized to the correct config hierarchy that you are in.

If you have incorrect settings in web.config file (which might be correct for a different Framework) then you get errors because of this work in Web MT to use the config files from the correct Framework hierarchy…

Picking correct version of Visual Studio Development Server (Cassini)

As you know we have Visual Studio Development Server (aka Cassini) which ships for local development of web projects within VS… In VS 2010 we will ship with two versions of Cassini EXEs, if you observe system tray balloons/pop-ups you will now notice either webserver40.exe or webserver20.exe… That is because Cassini runs outside the process of Visual Studio and for debugging your .NET 2.0/3.0/3.5 you actually want to run under CLR 2.0 and to try your .NET 4.0 apps you need to run under CLR 4.0… This will provide real framework experience during F5/Ctrl+F5 and View in Browser scenarios… Apart from various bug fixes that went into Cassini 4 this was another chunk of work for our QA team did to verify whether VS 2010 picked up correct version of Cassini or not…

There are several other things related to Multi targeting that I would like to ramble about, but if I do it right now it will just become too long to be read, instead I will hold off for now and continue  with Part 2 in next few days…

Till then my hope is that you will look at that small drop down box a little more next time and remember us all :-)

-Vishal

The remaining posts in the Web MultiTargeting Series are:

Wednesday, August 12, 2009

Fix-It: Nesting between .aspx and code behind is lost when you move files to a different folder

In this post I am hoping to cover a quick tip/trick about file nesting in ASP.NET Web Site Project.

Let’s say you have the below web site in your solution explorer:

nest files

If you move “About.aspx” and “About.aspx.cs”  to the “New Folder” shown above then you will see the file nesting in solution explorer incorrect…

To fix this issue there is a solution explorer button for “Nesting Related Files” as shown below…

image

When you click this button the project system should update the solution explorer and show you the nested files correctly…

-Vishal

Technorati Tags: ,



Fix-It: Multiple instances of Visual Studio Development server getting created

Sometimes while developing some of you might notice a lot instances of Visual Studio Development Server (aka Cassini) in your system tray… Many of these icons when clicked on land up just vanishing away and at times these icons may flood the system tray causing frustration…  Sorry for that :-(

One of the reasons for this happening is that ASP.NET Development server is set up to use dynamic port allocation as shown below:

WAP (Right Click Project –> Properties –> Web)

Auto-assign Port

Web Sites (Select Web Sites –> F4 to see properties)

image

Sometimes on some developer boxes either Windows firewall or custom firewall blocks a bunch of ports… In this situation Web Development Server tries to hook to one of the blocked ports port and is not allowed to… In the process the Development Server lands up crashing… Next time it tries to assign itself to another dynamic port and the same thing happens…  As a result there are various tray icons created even though the Web Development Server exe has actually crashed…  That is the reason when you hover over the icons in the system tray they vanish away…

Firstly, let me call out that this is a bug, I just verified it with our key dev Bill Hiebert and he confirmed that this is now fixed in VS 2010…  For the time being the work around for

VS 2008 developers is to go ahead and turn off the Auto-assign Port/Use Dynamic ports option and actually set a fixed port which you know is not blocked by one of your firewalls…  Hopefully with this the multiple icons in the system tray should no longer appear…

If you still face problem then do write back…

-Vishal




Multiple instances of Visual Studio Development server getting created

Sometimes while developing some of you might notice a lot instances of Visual Studio Development Server (aka Cassini) in your system tray… Many of these icons when clicked on land up just vanishing away and at times these icons may flood the system tray causing frustration…  Sorry for that :-(

One of the reasons for this happening is that ASP.NET Development server is set up to use dynamic port allocation as shown below:

WAP (Right Click Project –> Properties –> Web)

Auto-assign Port

Web Sites (Select Web Sites –> F4 to see properties)

image

Sometimes on some developer boxes either Windows firewall or custom firewall blocks a bunch of ports… In this situation Web Development Server tries to hook to one of the blocked ports port and is not allowed to… In the process the Development Server lands up crashing… Next time it tries to assign itself to another dynamic port and the same thing happens…  As a result there are various tray icons created even though the Web Development Server exe has actually crashed…  That is the reason when you hover over the icons in the system tray they vanish away…

Firstly, let me call out that this is a bug, I just verified it with our key dev Bill Hiebert and he confirmed that this is now fixed in VS 2010…  For the time being the work around for VS 2008 developers is to go ahead and turn off the Auto-assign Port/Use Dynamic ports option and actually set a fixed port which you know is not blocked by one of your firewalls…  Hopefully with this the multiple icons in the system tray should no longer appear…

If you still face problem then do write back…

-Vishal

Saturday, August 08, 2009

Web Application Project Vs Web Site

Few days back I summarized the difference between a project system and a project templates; today I want to focus on key differences between different project systems available for web developers in Visual Studio…

You might be aware of the fact that we have two different types of project systems for Web developers i.e Web Application Projects (WAPs) and Web Site Projects (WSPs)…  Often time I get asked this question on which type of project should to use for web development…  Sometimes web developers even start a religious war on the two choices, honestly here you have an option to choose the god of your own choice and this post is my attempt to help you make an informed decision…

Most of the time I land up asking questions to people before actually recommending a particular project system.  I will try to keep the format of this post in that similar fashion as it typically works out easier to come to a conclusion…  If you are in a hurry and do not care of about the inner workings then feel free to just read the questions (in bold) and the highlighted winning project system name in the answer :-)

Q1. Do you intend to deploy source code on your production server and edit it right on the server if there was a time sensitive bug reported ?

If you answered Yes to the above question, you want to use Web Site projects (WSPs)…  In case of Web Site projects Visual Studio does not really compile your source code on your dev box, it merely uses aspnet_compiler to validate that your source code will actually compile and run on the server…  Hence when you try to deploy a web site people typically also deploy the source code on the server which allows them to edit the source right on the production server if there was a time sensitive bug reported…

Q2. Conversely, are you sensitive about not having your source code openly available on production servers?

If you answered Yes then you want to use Web Application Projects (WAPs)… In case of WAPs the .aspx.cs or .aspx.vb files are actually compiled via VS and converted into a .dll which actually resides in the BIN folder of your project…  The generated dll is named as MyProject.dll by default (but you can change the name and also potentially strong name sign it if you care)… Hence in case of WAP projects you do not need to deploy you .aspx.cs or .aspx.vb files which prevents exposure of your source code, in case of WSP you need to deploy these files… The subtlety to note here is that Visual Studio in this case is actually calling C# or VB compilers to compile your .aspx.cs or .aspx.vb files whereas in case of Web Sites the ASP.NET RUNTIME compiler calls the C# and VB compilers internally on production servers...

Q3. Do you care to unit test your source code which is present in your .aspx.vb/.aspx.cs files?

I know this is a politically flaming question, don’t answer it aloud :-)… If you answered Yes then you want to use WAPs… As WAPs generate a DLL out of your .aspx.cs and .aspx.vb files you can very easily create a Unit Test project using MBUnit, NUnit, VS Unit Test etc and add a reference to the WAP DLL…  In case of WSPs there is no DLL generated on developer box hence it is difficult to reference that code and write unit tests for them…  Not that it is not doable but it is not very intuitive and easy as in case of WAPs…

Also additionally if you have factored your C#/VB source code in a class library and are unit testing that library then WSP projects will work just fine…

Q4. Do you want many developers editing the deployed site as and when required by going to the server ?

If you answered Yes then refer to Q1. the rationale is simple WAP does not give you an option to edit .aspx.cs or .aspx.vb files on the server directly hence you need to use WSP in this case…

Q5. Do you use Source Code Control like VSS or Team Foundation Server to store your sources ?

This question was just for fun and clarity… :-) It does not matter whether you are using WAP or WSP… There is full source code control integration available with both project types so this is not really a deciding factor…   Similarly debug, run, view in browser etc all work no matter which project system you choose…

Q6. Do you intend to use Team Build/Cruise Control.NET etc to create a nightly/rolling builds or set up Continuous Integration?

If you answered Yes then ideally you are better off with WAP…  WAP is actually a MSBuild based project system and as you may be aware MSBuild is the basis of most command line build/test/deploy model for projects created by Visual Studio...  It contains .csproj or .vbproj file which contains all the MSBuild semantics to be able to build/compile/deploy your web project, hence it is very easy to set up command line builds, deployments etc with WAPs.  WSPs on the other hand have no .csproj or .vbproj files, we provided rudimentary support for WSP to use command line build using Solution Files (.sln)…  It is not rocket science to have WSP projects build in Team Build/CC.NET but the fact is that when WSPs were designed back in VS 2005 continuous integration (CI) was not the primary scenario rather quick easy editing of web pages was a higher priority… 

A different way of thinking about this is that there can be a lot of generic MSBuild based plug-ins (tasks/targets) which can out of the box work for WAPs but will need your own manual tweaking around to get them to work with WSP…  Essentially this decision point is not as black n white but without doubt WAPs will be way easier when it comes to MSBuild/Team Build support…

Q.7 Do you intend to remotely connect to your web and edit it via FTP?

Many people create their web sites and deploy it to a remote server… Eventually, they want to be able to connect to these LIVE sites from Visual Studio and edit them live by adding more features to them, fixing bugs etc…  If you are one of these folks then WSP is a better bet for you as WSP allow you to open a Web Site on the server and edit it right inside of Visual Studio… Again it boils down to the fact that the server actually has your source code so it is possible to edit it via FTP or FPSE and as WAPs do not have source code it does not really make sense to try to edit them…

While we are on this topic, let me mention  “please try to avoid using FPSE, it is a deprecated technology on the server side and sooner or later Visual Studio will stop supporting it”…

Q.8 Is there a possibility that you might ever loose your source code from your dev box if your hard disk crashed and you never had source code control back up?

Sounds like a silly question right, but many times for my personal web sites I do land up in this bucket… Recently I lost the source code for a portion of KritZu project, well it was a windows app but the point is that for my tiny home grown projects I sometimes do not have a proper source control repository…

Anyways in this scenario if you had a WSP and had deployed it with source code on the server then you might be better off… But then honestly this is a silly reason, please create back up of your source code somewhere and don’t use this as a differentiating factor…  Additionally in VS 2010 you can also create source package of your project and potentially save them somewhere, it makes creating back ups for source code in WAPs much easier, so in case of VS 2010 you can also use WAP equally well for this scenario…

Q.9 Do you intend to update just few .aspx and .aspx.cs/.aspx.vb files and do not want to recompile your project?

If you answered Yes you want to use WSPAgain as described in Q.1, 2, and 4 above Web Site project has source code on the server and it gets compiled there so if you just want to update one file and push it on the server then you do not need to recompile your project.  This is the very reason why “Copy Web Site” feature is available only with WSP and not with WAP… In case of WAP as all the .aspx.vb/.aspx.cs files are actually compiled into a DLL if you want to just change one of it you have to recompile….

NOTE:  If you just want to change .aspx files and not .aspx.vb/.aspx.cs then WAP is equally good… 

Q.10 Do you intend to leverage Web Deployment features of VS 2010 and MsDeploy?

If you answered Yes then you want to use WAPs…  There are tons of Web Deployment features available in VS 2010 for WAPs, some of them are:

Not that the above features will be supported in Web Site someday but we initially implemented the entire feature set on MSBuild so that it can be supported in a CI model on CC.NET/Team Build and as it is very straightforward to hook MSBuild WAPs was the de-facto choice… WSPs do not have a project file and hence trying to implement this for WSP will require a major changes in WSPs which we are not able to accommodate within VS 2010 box

Q.11 Have you heard of Web Deployment Projects for VS 2005 and VS 2008?

Web Deployment Projects (WDP) are an add on to VS 2005 (Download WDP 2005)and VS 2008 (Download WDP 2008)… WDP is a MSBuild based project and it has its own project file… It essentially takes the output of WAP or WSP and pre-compiles/merges it into DLLs which are ready to be deployed… Essentially WDP does the compilation that ASP.NET Compiler would do at RUNTIME and so if you use them during build time then your web pages’ FIRST TIME load performance will significantly improve (as ASP.NET will not have to compile the pages on the server)…

For WSP this means that you get some of MSBuild benefits of integration with Team Build/CC.NET but then you loose the flexibility of having your source code on the server and editing it anytime you want…  In any case WDP in my opinion should NOT be one of the deciding points while choosing WAP or WSP, in fact  WDP works just fine with both the project systems… 

Many people try to use WDP to get Team Build style benefits on WSPs but then I would recommend pausing and asking yourself a question “Why are you using WSP if you are about to loose many of the advantages of WSP like being able to edit code files anytime, etc?

So from WDP standpoint either WAP or WSP is equally ok…

Q.12. Do you write inline C# or VB code in .aspx files (in addition to / instead of writing it in .aspx.cs or .aspx.vb)?

People sometimes do write <script runat=”server”> int i;</script> or <%= %> style code inside the .aspx pages… If you do so you should note that WSP provide better intellisense and refactoring here… But most of the times the difference is not very noticeable in WAPs either (at least not many people are screaming about  it :-))…  So if you leave that part alone both WAP or WSP work the same from this standpoint…

The code written in .aspx pages EVEN IN CASE OF WAP does not get compiled by VS… The code in .aspx pages is left as is and is compiled by ASP.NET compiler on the server… So essentially even if you are using WAPs you can also edit the code written in .aspx on the production server… Certainly, you can do this with WSP too…

So when it comes to writing inline C# & VB code WSP and WAPs are more or less the same…

Q.13 Do you aspire to write both VB and C# code in a single Web Project?

What if people who love VB could write VB code and people who love C# could write C# code and they both can work on the same project at the same time… Interesting idea right…?  You can imagine that in some community project people may decide to do this… In enterprises or formal companies I have never seen this happen due to maintainability reasons…  Anyways, even for kicks if you want to write both VB and C# code in the same Web Project it is way more simpler to do so in WSP than in WAP… 

Again it is not impossible to do it in WAPs but slightly more convoluted…  The reason why it is complicated to do this in WAP is coz WAP compiles everything based on the project file which is either vbproj or csproj… WSP on the other hand is just a folder and ASP.NET RUNTIME can call any compiler based on the file extension… There are some ifs and buts and maybe someday I will write about them but for now WSP is more preferred in this scenario…

Q.14 Have you heard of ASP.NET MVC projects?

In  my Project template vs. Project system post I had mentioned that ASP.NET MVC Projects are a type of WAP…  To further explain it MVC Projects are essentially what we call as “Flavor” of WAP…  Flavor is a special little “lingo” of VS :-) think of it as a special type of inheritance i.e. MVC Projects flavor WAP Projects who in turn flavor Class Library projects and all along the line you keep getting more an more features while the child projects can hide features of the parent as well…  For e.g. MVC projects hide “View in Browser” command while adding “Add a View” command…We can talk more about this some other time but in nutshell MVC projects have got controllers and model classes which all get compiled into DLLs and the Views get deployed as they are on to the server…

MVC projects also are pro on Unit Testing so in lines with Q3. we just decided to avoid any confusion and just created MVC projects for WAPs… So if you are using ASP.NET MVC you are most likely using WAPs… Again using ASP.NET MVC with WSP is possible, it is just not straightforward option and some IDE features may not be available out of the box if you were using MVC with WSP today…

Q.15 Do you want to edit your code while debugging (w/o stopping debugging)?

Edit & Continue feature is supported only in WAP projects and not WSP hence if you care about Edit & Continue then WAP is your option of choice…

In conclusion, there are more subtle things to look out for… e.g. Few days back I explained why App_Code does not work all that well with WAPs…  But other things should be hopefully minor issues and the above decision points should hopefully allow you to make an informed decision when WAP vs WS discussion comes up again…:-)

There are more subtle differences between WAP and WSPs and some of them are discussed in the white paper on MSDN

Hope this discussion helps and do not hesitate to reach out if you would like to know anything in more details…

-Vishal

Wednesday, August 05, 2009

VS Project Template Vs Project System

You might many times hear the words “project templates” and “project system” from time to time, I though it would be worth while to talk about the differences between the  two from a web developer stand point…

Web developers using Visual Studio use either File –> New –> Project or File –> New –> Web site as shown below to create new Web projects as shown below:

File-New-Project

The new project dialog for Web Developers looks as below:

new project

and the new web site dialog looks as below:

new web site

What is probably interesting to note is that all the options that you see inside any of these dialog boxes above are just “Project Templates” and what that really means is that they are underlying the same project system but just wrapped with different set of start up files for easy project development…

In reality there are only two major Project Systems for Web Developers

  1. Web Application Projects (WAPs) which are accessible via File –> New –> Project –> Web
  2. Web Site Projects (WSPs) which are accessible via File –> New –> Web Site

What is also interesting to note is that WAPs and WSPs have different code bases (with reasonable set of shared components)… I will eventually write a post on real differences between WAPs and WSPs but today let us focus on Project Systems vs Templates…

A Project system like WAP or WSP actually takes care of building, compiling, debugging, managing source control, deploying, hooking up references, intellisense etc etc  for a project…  In essence the major code for functionality of the web project like commands, hot keys, content menus, toolbars etc are all specific to a project system and they remain the same across all the project templates of a single project system…

A Project template on the other hand is simply a bunch of files bundled together to allow a person to easily start developing a certain type of project…   The project templates can have specific files like .svc or .aspx with boiler plate code in it… Each project template can choose to include its own set of references or code files… Behind the scene the project system invoked to do all the magic remains the same… For example ASP.NET Web Application and WCF Service Application are just two different templates for “Web Application Project System”…  Similarly there are a bunch of project templates for “Web Site Project System”…

The key Project templates for Web Application Projects (WAP) are:

  • ASP.NET Web Application
  • Empty ASP.NET Web Application
  • ASP.NET Web Service Application
  • WCF Service Application
  • Dynamic Data Linq to SQL Web Application
  • ASP.NET MVC Web Application (MVC is a customized Web Application Project system, we call it Flavor of WAP, so it is not necessarily a project template only…)
  • Dynamic Data Entities Web Application

Similarly, the key Project templates for Web Site Project (WSP) are:

  • ASP.NET Web Site
  • Empty Web Site
  • WCF Service
  • ASP.NET Reports Web Site
  • Dynamic Data Linq to SQL Web Site
  • Dynamic Data Entities Web Site

Hence many a times there are features which work for one project system but do not work for other… A classic example is App_Code directory which works great with Web Site projects but not as seamlessly with Web Application Projects…  Recently I wrote a blog post on Why App_Code does not work as well with WAPs

Anyways, I hope this gives an idea on how the project systems and project templates for Web Developers work within Visual Studio…

-Vishal

Tuesday, August 04, 2009

Did you know: How to get “Unload Project” option to show

Typically if you want to edit your .csproj or .vbproj file manually then there is a very easy way to do this within VS:

First: Unload the project within VS

Unload Project

Second: On the unloaded project click “Edit project.csproj/vbproj”

Reload Project

Now you can edit the file and click “Reload Project”…

Although at times you might not see the “Unload Project” menu and  it is interesting to note that this menu shows only when your solution is showing up… The solution shows up when you have more than one project but if you have only one project in your solution then solution file does not show by default…  If you want to have the solution file show in the solution explorer then you can go down to Tools > Options > Projects and Solutions > General and check “Always show solution”…

Tools Options

After this your “Unload Project” menu should start showing up on your project file.

-Vishal

Replacing your old DB with new one using VS 2010

Earlier in the below blog posts we had talked about how to Deploy your DB using VS 2010…

Today I wanted to share how you can replace your old DB with a new one using VS 2010 DB Deployment.

Before we get into it please note that using this method you are essentially going to get rid of your old DB schema as well as data and replace it with the new one…  You should make sure that you do not turn this setting on accidentally as there will be no way to revert it back if you accidentally drop your DB content… !!

So with that understanding and with the assumption that you have already, configured your DB for deployment for use with Web Packaging OR 1-Click Publish; let us proceed:

After configuring your DB for Deployment your “Deploy SQL” Property tab should look something like below:

Deploy SQL Tab

If you look at the above UI, you will notice that there is no UI option to drop your database objects during Packaging or Publishing… This was an intentional decision as we did not want anyone to accidentally check that box and regret later… Although you can do this by manually by editing your project file…

To do that you will have to Right Click on your project and click “Unload Project” as shown below:

Unload Project

Once you unload your project you will have an option to Edit your project file as shown below:

image

Alternatively you can also open your project folder and edit the project file in notepad…

If you have your DB deployment configured in “Deploy SQL” tab (shown above) of your project properties then you should find following XML schema in the project file:

<PublishDatabaseSettings>
      <Objects>
        <ObjectGroup Name="MyDB" Order="1" Enabled="False">
          <Destination Path="" />
          <Object Type="dbFullSql">
            <PreSource Path="your connectionString value" ScriptDropsFirst=”True” ScriptSchema="True" ScriptData="False" SchemaQualify="False" CopyAllFullTextCatalogs="False" />
            <Source Path="obj\Debug\AutoScripts\MyDB_SchemaOnly.sql" />
          </Object>
        </ObjectGroup>
      </Objects>
</PublishDatabaseSettings>


If you notice carefully you should see that in the “PreSource” node above I have



additionally inserted a special attribute called ScriptDropsFirst=”True”, this attribute will tell the Web Publishing Pipeline (WPP) to insert DROP statements while scripting your DB…



In nutshell the PreSource node tells VS 2010 about your source DB and the options you would like to use while script it… ScriptDropsFirst is only one of the options but there are several others properties that you can set to control the scripting of your DB which are mentioned in SMO Scripting Options.



The option of ScriptDropsFirst will not drop your Database it will simply drop the objects inside the Database… If you would also like to drop the Database and recreate it you should use the option dropDestinationDatabase=”True”. If you are deploying to a hoster like DiscountASP or OrcsWeb you should NOT use dropDestinationDatabase option as most likely you will not have the permission to do so and even if you did the chances are that you will not have an option to recreate it and you might have to land up calling the support center…  Hopefully if you are deploying to a hosted server then you will not need to drop the DB and just dropping the schema and data inside it will be sufficient…



Anyways, once you have set these attributes  on your preSource node you can now save the project file and reload it… After that next time you Package or Publish your deployment will first drop all the tables, columns and data in your destination DB and then recreate it using the newly generated SQL script…



-Vishal