-
| 
|
My book on MSBuild and Team Build
| Archives and Categories
Friday, June 15, 2012
I have written a few posts recently describing out updated web publish experience. These new experience is available for both Visual Studio 2010 as well as Visual Studio 2012 RC. You can use the links below to download these updates in the Azure SDK download. Below are links for both versions.
The Web Publish experience is chained into VS 2012 RC so if you have installed VS 2012 RC with the Web features then you already have these features.
Thanks,
Sayed Ibrahim Hashimi @SayedIHashimi
Last week we rolled out some updates for our Visual Studio 2010 Web Publishing Experience. This post will give you an overview of the new features which we released. In the coming weeks there will be more posts getting into more details regarding individual features.
You can get these updates in the Windows Azure SDK for Visual Studio 2010. When you download that package there you will also get the latest tools for Azure development.
The new high level features include the following.
- Updated Web Publish dialog
- Support to import publish profiles (.publishSettings files)
- Support to configure EF Code First migrations during publish
- Support to create web packages in the publish dialog
- Publish profiles now a part of the project and stored in version control by default
- Publish profiles are now MSBuild files
- Profile specific web.config transforms
Overview
When you right click on your Web Application Project (WAP) you will now see the new publish dialog.
On this tab you can import a .publishSettngs file, which many web hosts provide, and you can also manage your publish profiles. If you are hosting your site on Windows Azure Web Sites then you can download the publish profile on the dashboard of the site using the Download publish profile link. After you import this publish profile you will be brought to the Connection tab automatically.
On this tab you can see all the server configuration values which are needed for your client machine to connect to the server. Typically you don’t have to worry about the details of these values. Next you’ll go to the Settings tab.
On the Settings tab you can set the build configuration which should be used for the publish process, the default value here is Release. There is also a checkbox to enable you to delete any files on the server which do not exist in the project.
Below that checkbox you will see a section for databases. The sample project shown has an Entity Framework Code First model, named ContactsContext, and it uses Code First Migrations to manage the database schema. If you have any non-EF Code First connection strings in web.config then those databases will show up as well but the support for incrementally publishing the schema for those has not yet been finalized. We are currently working on that. You can visit my previous blog entry for more info on that.
If you imported a .publishSettings file with a connection string then that connection string would automatically be inserted in the textbox/dropdown for the connection string. If you did not then you can use the … button to create a connection string with the Connection String Builder dialog or you can simply type/paste in a connection string. For the EF Code First contexts you will see the Execute Code Frist Migrations checkbox. When you check this when your site is published the web.config will be transformed to enable the Code First migrations to be executed the first time that the context is accessed. Now you can move to the Preview tab.
When you first come to the Preview tab you will see a Start Preview button. Once you click this button you will see the file operations which would be performed once you publish. Since this site has never been published all the file operations are Add, as you can see in the image below. The other Action values include; Update and Delete.
Once you are ready to publish you can click the Publish button. You can monitor the progress of the publish process using the Output Window. If your publish profile had a value for the Destination URL then the site will automatically be opened in the default browser after the publish has successfully completed.
Publish Profiles
One of the other changes in the publish experience is that publish profiles are now stored as a part of your project. They are stored under the folder Properties\PublishProfiles (for VB projects its My Project\PublishProfiles) and the extension is .pubxml. You can see this in the image below.
These .pubxml files are MSBuild files and you can modify these files in order to customize the publish process. If you do not want the publish profile to be checked into version control you can simply exclude it from the project. The publish dialog will look at the files in the PublishProfiles folder so you will still be able to publish using that profile. You can also leverage these publish profiles to simply publishing from the command line. For example you can use the following syntax to publish from the command line.
msbuild.exe WebApplication2.csproj /p:DeployOnBuild=true;PublishProfile="pubdemo - Web Deploy";Password={INSERT-PASSWORD}
Resources
If you have any questions please feel free to directly reach out to me at sayedha(at){MicrosoftDOTCom}.
Sayed Ibrahim Hashimi @SayedIHashimi
Thursday, June 07, 2012
We have two sets of ASP.NET providers which currently exist; the ASP.NET SQL providers, and the ASP.NET Universal Providers. In VS 2010 the SQL providers were in only providers used for our project templates. In VS 2012 we have switched to using the Universal Providers. One of the drawbacks of the SQL providers is that it leverages DB objects of SQL server which are not available in SQL Azure.
In our updated web publish experience we have an Update Database checkbox which can be used to incrementally publish the database to the destination database. In this case if the source connection string is used by the ASP.NET SQL providers and you are publishing to SQL Azure then you will see the following message on the dialog.
Note: you may see the Update Database checkbox disabled, please visit http://sedodream.com/2012/06/07/VSPublishDialogUpdateDatabaseDialogDisabled.aspx for more info on why.
The publish dialog is letting you know that the SQL providers are not compatible with SQL Azure and helps you convert to using the Universal Providers. After you install the Universal Providers the web.config entry will be commented out and new entries will be inserted for the Universal Providers. Your existing database will not be impacted, we’ll create a new connection string pointing to a new database. If you had any data in the SQL Providers database you will have to re-create those objects in the new database.
If you have any questions please feel free to directly reach out to me at sayedha(at){MicrosoftDOTCom}.
Sayed Ibrahim Hashimi @SayedIHashimi
In Visual Studio 2010 we introduced a database publishing experience in the Package/Publish SQL (PP/SQL) properties page. This support relies on generating create scripts from the source database and then executing those scripts when you publish your web application. For more details regarding this feature take a look at Package/Publish SQL Tab, Project Properties. One of the negative aspects of the implementation that we have there is that the DB schema publishing is not incremental, it always executes create scripts. So in many cases you publish your app for the first time and things are great, but the next time you try to publish you receive errors because it tries to create DB objects which already exist.
In our improved publish dialog we have a new database publishing experience which is incremental, so you don’t run into the same issues when re-deploying your database. All of the configuration for this is within the publish dialog itself. If you have a project which already has DB publish settings on the Package/Publish SQL tab (under any build configuration/platform) then you will see the message shown in the image below.
The new incremental DB schema publish mechanism is not compatibly with the feature set on the PP/SQL tab. For each web publish profile you can either use the settings on the PP/SQL tab or you can opt-in to the new experience on the publish dialog. We implemented it this way in order to introduce the new feature set and to ensure that existing publish scenarios are not broken.
FYI there is a related post on why the Update database checkbox is disabled in the publish dialog which you may be interested in.
If you have any questions please feel free to directly reach out to me at sayedha(at){MicrosoftDOTCom}.
Sayed Ibrahim Hashimi @SayedIHashimi
If you have tried out our new Web Publish experience in Visual Studio you may have noticed that the Update Database checkbox is disabled. See the image below.
The intended behavior of this checkbox is to enable you to incrementally publish your database schema from the source (the connection string in web.config) to the destination (whatever connection string is in the text box). The difference between an incremental publish and a typical publish is that for incremental publishes only changes are transferred from source to destination. With a full publish the first time that you publish your DB schema everything is created, and the next time that you try to publish you will receive an error because it tries to re-create existing DB objects.
The functionality of the Update database checkbox leverages an MSDeploy provider. We were hoping to complete that provider and give it to hosters in time for the release but we were unable to do so. We are working on completing the provider and partnering with hosters to install these in time for the launch of Visual Studio 2012 RTM.
In the mean time if you need to publish your DB schema you can use the Package/Publish SQL tab (caution: the DB publishing here is not incremental). If you are going to use the PP/Sql tab to publish to SQL Azure then there are some special consideraions that you will need to take. You can learn more about those by visiting http://msdn.microsoft.com/en-us/library/dd465343.aspx and searching for “Azure” on that page.
If you have any questions please feel free to directly reach out to me at sayedha(at){MicrosoftDOTCom}.
Thanks,
Sayed Ibrahim Hashimi @SayedIHashimi
Thursday, May 24, 2012
Wanted to let you know that I just released v2.3 of my Visual Studio extension SlowCheetah. If you are not familiar with SlowCheetah here is an intro. For client projects (i.e. non-web projects) it allows you to transform the app.config (or any XML file) on F5 (debug) or CTRL + F5, it also has a preview functionality which allows you to see the results of the transform quickly. For Web Projects it allows you to transform XML files during package/publish (and of course the preview functionality works in web projects too). The transform behavior is all in MSBuild targets/tasks so command line support is built in. It’s also easy to integrate SlowCheetah into CI servers.
Below are the updates that we have in v2.3.
Preview support in VS 11
In the previous version we added support for VS 11 but the preview functionality didn’t work because the preview tool we used in VS 2010 didn’t exist in VS 11. VS 11 now has a new diffing tool and in this version we now support invoking this new service.
ClickOnce related updates
ClickOnce support was added in a previous version but the support was limited to app.config. In this version when you publish an application using ClickOnce if you have transforms in any other XML file defined those transforms will be applied and published.
Setup projects updates
Similar to ClickOnce the support for setup projects was limited to app.config only. In this version we now have support for all XML files not just app.config. There was also a bug in the previous version relating to setup projects. For setup projects if a file was being transformed from a linked file when you built the solution you would receive an error. We have fixed that bug.
Sayed Ibrahim Hashimi @SayedIHashimi
SlowCheetah
Thursday, May 24, 2012 8:18:22 AM (GMT Daylight Time, UTC+01:00)
|
Monday, May 14, 2012
I was on StackOverflow today and noticed a question along these lines “How to I create a target which is executed when CoreCompile is, and that is skipped when CoreCompile is skipped?” Below is my answer.
This is a tricky problem to solve for the general case, but it is pretty easy in your case because CoreCompile has special built in support for this scenario. Before I go into the details of how you can accomplish this with CoreCompile let me explain how it works in general.
Explanation of the general case
In MSBuild targets are skipped due to Incremental Building. Incremental Build is driven purely off of the Inputs and Outputs attributes on the Target itself. The inputs are a list of files that the target will "use" and the outputs are a list of files that are "generated" by the target. I'm using quotes because its a loose concept not a concrete one. To simplify it you can just treat inputs/outputs as lists of files. When the target is about to be executed MSBuild will take the inputs and compare the timestamps of them to the outputs. If all the outputs are newer then the inputs then the target will be skipped. (FYI If you want to know what happens when only some outputs are out-of-date read my blog athttp://sedodream.com/2010/09/23/MSBuildYouveHeardOfIncrementalBuildingButHaveYouHeardOfPartialBuilding.aspx).
In any case if you want a target to be skipped you have to craft your Inputs/Outputs correctly. In your case you want to skip your target whenever the CoreCompile is skipped, so at the surface it would seem that you could simply copy the Inputs/Outputs of CoreCompile but that doesn't work. It doesn't work because when CoreCompile is executed the files may be out-of-date but that target itself brings them up-to-date. Then when you target is executed since they are all up-to-date it will be skipped. You would have to copy the Inputs/Outputs and append an additional file to inputs/outputs which you target creates. This would ensure that your target wouldn't get skipped during that first pass.
Specific solution for CoreCompile
If you take a look at the project file you will see towards the bottom that the file Microsoft.Common.targets is Imported, this file will then import the language specific .targets file. For example it will Import either Microsoft.CSharp.targets or Microsoft.VisualBasic.targets (if you are using C# or VB). In those .targets files you will find CoreCompile defined. In the definition for CoreCompile you will find the following at the end.
<CallTarget Targets="$(TargetsTriggeredByCompilation)" Condition="'$(TargetsTriggeredByCompilation)' != ''"/>
This will call all the targets defined in the TargetsTriggeredByCompilation property. So if you want your target to be called whenever CoreCompile is executed you can extend that property. Here is how to do that.
<PropertyGroup>
<TargetsTriggeredByCompilation>
$(TargetsTriggeredByCompilation);
MyCustomTarget
</TargetsTriggeredByCompilation>
</PropertyGroup>
<Target Name="MyCustomTarget">
<Message Text="MyCustomTarget called" Importance ="high"/>
</Target>
In this case I define the property TargetsTriggeredByCompilation and I append MyCustomTarget to it. It's very important that you include the $(TargetsTriggeredByCompilation); there, if you don't then you won't be appending but overwriting. So if anyone else used this technique you'd wipe out their target.
Below is an image showing where I build once and CoreCompile and MyCustomTarget are executed. Then the second build CoreCompile is skipped any MyCustomTarget is never called.
Sayed Ibrahim Hashimi @SayedIHashimi
Sunday, May 13, 2012
If you have used the Visual Studio web publish in either VS 2010 or VS 11 to create Web Deploy packages then you probably know that we parameterize connection strings in web.config automatically. In case you are not familiar with Web Deploy parameters, they are a way to declare that you want to easily be able to update a value of something when publishing the package later on. Connection strings are good examples of something which typically needs to be updated during publish.
As I previously stated if you create a Web Deploy package in Visual Studio we will automatically create Web Deploy parameters for all your connection strings in web.config. Earlier today I saw a question on StackOverflow asking how to parameterize connection strings in non-web.config files (question actually asked something else, but I think this is what he’s really wanting). I created a sample showing how to do this. Below is what the connectionStrings element looks like in web.config.
<connectionStrings configSource="connectionStrings.config" />
And here is connectionStrings.config
<?xml version="1.0" encoding="utf-8" ?>
<connectionStrings>
<clear/>
<add name="ApplicationServices"
connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true"
providerName="System.Data.SqlClient" />
<add name="OtherConnectionString"
connectionString="data source=.\SQLExpress;Integrated Security=SSPI;Initial Catalog=foo"
providerName="System.Data.SqlClient"/>
</connectionStrings>
In order to parameterize these connection strings you will have to extend the Web Publish Pipeline. To do that create a file named {project-name}.wpp.targets in the root of the project in which you are working (for VS 11 projects you can place all this directly inside of the .pubxml files). This will be an MSBuild file which will get imported into the build/publish process. Below is the file which needs to be created.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<!-- Here we need to declare MSDeploy parameters for connection strings in connectionStrings.config -->
<MsDeployDeclareParameters Include="ApplicationServices-ConnectionString" >
<Kind>XmlFile</Kind>
<Scope>connectionStrings.config$</Scope>
<Match>/connectionStrings/add[@name='ApplicationServices']/@connectionString</Match>
<Description>Connection string for ApplicationServices</Description>
<DefaultValue>data source=(localhost);Initial Catalog=AppServices</DefaultValue>
<Tags>SqlConnectionString</Tags>
</MsDeployDeclareParameters>
<MsDeployDeclareParameters Include="OtherConnectionString-ConnectionString" >
<Kind>XmlFile</Kind>
<Scope>connectionStrings.config$</Scope>
<Match>/connectionStrings/add[@name='OtherConnectionString']/@connectionString</Match>
<Description>Connection string for OtherConnectionString</Description>
<DefaultValue>data source=(localhost);Initial Catalog=OtherDb</DefaultValue>
<Tags>SqlConnectionString</Tags>
</MsDeployDeclareParameters>
</ItemGroup>
</Project>
Here you can see that I am creating values for MSDeployDeclareParameters. When you package/publish this item list is used to create the MSDeploy parameters. Below is an explanation of the metadata values each contain.
- Kind = for this case it will always be Xmlfile, learn more
- Scope = a regular expression to the file which needs to be modified
- Match = an XPath expression to the attribute/element to be updated
- Description = optional description (this will show up in the IIS manager if the pkg is imported)
- DefaultValue = optional default value for the for the parameter
- Tags = optional, for connection strings use SqlConnectionString
After you create this file you will need to close/re-open VS (it caches imported .targets files). Then you can create a web deploy package. When you do so these new parameters will be declared. In my case I then imported this in the IIS manager and here is the dialog which shows up for the parameters.
As you can see the Application Path parameter is shown there as well as my custom connection string values. When I update the values in the text box and opened connectionStrings.config on my web server they were the values I entered in the dialog box.
FYI I have uploaded this sample to my github account at ParameterizeConStringConfig.
Sayed Ibrahim Hashimi @SayedIHashimi
Saturday, May 12, 2012
\I receive a lot of questions regarding web.config transforms, which have existed in Visual Studio since 2010, and wanted to clear up the support that we have in this area. These transforms show up in the solution explorer underneath web.config as shown in the image below.
Since the names of these transforms include the build configuration many people expect that web.config will be transformed when they start debugging (F5) or run the app (CTRL+F5) in Visual Studio. But sadly this is not the case. These transforms are kicked in only when the web is packaged or published. I totally agree that this would be awesome, and I even blogged about how to enable it at http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx. It may seem like it would be really easy for us to include this support in the box, but unfortunately that is not the case. The reason why we are not able to implement this feature at this time is because a lot of our tooling (and many partners) relies on web.config directly. For example when you drag and drop a database object onto a web form, it will generate a connection string into the web.config. There are a lot of features are like this. It is a significant investment for us to make a change of this level. We were not able to get this done for Visual Studio 11, but it is on our radar and we are looking to see what we can do in this area in the future.
Sayed Ibrahim Hashimi @SayedIHashimi
Sunday, May 06, 2012
Have you ever tried to perform an operation on a file (i.e. delete) just to be faced with an error relating to the fact that an application is locking the file? This happens to me a lot, including just now. I was writing some code and tried to switch branches and was given the error below.
So I closed down Visual Studio as well as IIS Express as I figured those were the ones which had the lock on the file, and tried again (a few times actually 
) but continued to receive the error above. In order to determine which file had a handle open to that file I downloaded Handle from the sysinternals suite. (I actually already had the items downloaded inside of a Dropbox share which I use between multiple computers.) I then executed the command handle.exe nlog and the results are shown below. Note: I had to open a command prompt window to run handle.exe, for some reason it wasn’t working from a PowerShell prompt.
As you can see there was a rogue devenv.exe process holding on to the file. After killing the process I was able to proceed.
Sayed Ibrahim Hashimi @SayedIHashimi
diagnostic |
windows
Sunday, May 06, 2012 12:53:04 AM (GMT Daylight Time, UTC+01:00)
|
| On this page |
Archives |
Categories |
|
| June, 2013 (4) |
| May, 2013 (2) |
| March, 2013 (3) |
| February, 2013 (3) |
| January, 2013 (3) |
| December, 2012 (3) |
| November, 2012 (1) |
| October, 2012 (3) |
| August, 2012 (6) |
| July, 2012 (2) |
| June, 2012 (5) |
| May, 2012 (6) |
| April, 2012 (3) |
| March, 2012 (1) |
| February, 2012 (3) |
| January, 2012 (1) |
| December, 2011 (3) |
| November, 2011 (3) |
| August, 2011 (1) |
| March, 2011 (1) |
| February, 2011 (1) |
| January, 2011 (1) |
| December, 2010 (2) |
| November, 2010 (3) |
| October, 2010 (3) |
| September, 2010 (2) |
| August, 2010 (2) |
| July, 2010 (2) |
| June, 2010 (3) |
| May, 2010 (3) |
| April, 2010 (5) |
| March, 2010 (8) |
| February, 2010 (2) |
| January, 2010 (2) |
| December, 2009 (2) |
| November, 2009 (4) |
| October, 2009 (3) |
| September, 2009 (2) |
| August, 2009 (5) |
| July, 2009 (2) |
| June, 2009 (7) |
| May, 2009 (4) |
| April, 2009 (5) |
| March, 2009 (1) |
| February, 2009 (2) |
| January, 2009 (2) |
| December, 2008 (2) |
| November, 2008 (1) |
| October, 2008 (1) |
| September, 2008 (1) |
| July, 2008 (1) |
| June, 2008 (5) |
| May, 2008 (2) |
| April, 2008 (2) |
| March, 2008 (1) |
| February, 2008 (5) |
| January, 2008 (2) |
| November, 2007 (2) |
| October, 2007 (1) |
| September, 2007 (1) |
| June, 2007 (1) |
| April, 2007 (1) |
| February, 2007 (1) |
| January, 2007 (1) |
| November, 2006 (2) |
| August, 2006 (3) |
| July, 2006 (2) |
| June, 2006 (5) |
| May, 2006 (2) |
| April, 2006 (2) |
| March, 2006 (6) |
| February, 2006 (2) |
| January, 2006 (8) |
| December, 2005 (4) |
|
|
![[RSS]](http://sedodream.com/images/feedButton.gif)