Just a quick snippet for doing the following (mainly for myself):
- Performing actions conditionally as part of a build process
- List of available variables
- Invoking the TransformXml Tasks
- Invoking the Copy Tasks
- <Target Name="AfterBuild" >
- <CallTarget Condition="$(IsTFSPackagingBuild)=='True'" Targets="TFSBuild" />
- <CallTarget Condition="$(IsTFSPackagingBuild)!='True'" Targets="LocalBuild" />
- <Target Name="TFSBuild" >
- <DeleteAfterBuild Include="$(WebProjectOutputDir)\Web.*.config" />
- <TransformXml Source="Web.config" Transform="Web.TEST.config" Destination="$(WebProjectOutputDir)\Web.TEST.config.transform" />
- <TransformXml Source="Web.config" Transform="Web.QA.config" Destination="$(WebProjectOutputDir)\Web.QA.config.transform" />
- <TransformXml Source="Web.config" Transform="Web.PROD.config" Destination="$(WebProjectOutputDir)\Web.PROD.config.transform" />
- <Delete Files="@(DeleteAfterBuild)" />
- <MySourceFiles Include="Web.config.transform" />
- <MyDestinationFiles Include="Web.config" />
- <Target Name="LocalBuild" >
- <Message Text="MSBuild: $(MSBuild)"/>
- <Message Text="MSBuildBinPath: $(MSBuildBinPath)"/>
- <Message Text="MSBuildExtensionsPath: $(MSBuildExtensionsPath)"/>
- <Message Text="MSBuildExtensionsPath32: $(MSBuildExtensionsPath32)"/>
- <Message Text="MSBuildExtensionsPath64: $(MSBuildExtensionsPath64)"/>
- <Message Text="MSBuildLastTaskResult: $(MSBuildLastTaskResult)"/>
- <Message Text="MSBuildNodeCount: $(MSBuildNodeCount)"/>
- <Message Text="MSBuildOverrideTasksPath: $(MSBuildOverrideTasksPath)"/>
- <Message Text="MSBuildProgramFiles32: $(MSBuildProgramFiles32)"/>
- <Message Text="MSBuildProjectDefaultTargets: $(MSBuildProjectDefaultTargets)"/>
- <Message Text="MSBuildProjectDirectory: $(MSBuildProjectDirectory)"/>
- <Message Text="MSBuildProjectDirectoryNoRoot: $(MSBuildProjectDirectoryNoRoot)"/>
- <Message Text="MSBuildProjectExtension: $(MSBuildProjectExtension)"/>
- <Message Text="MSBuildProjectFile: $(MSBuildProjectFile)"/>
- <Message Text="MSBuildProjectFullPath: $(MSBuildProjectFullPath)"/>
- <Message Text="MSBuildProjectName: $(MSBuildProjectName)"/>
- <Message Text="MSBuildStartupDirectory: $(MSBuildStartupDirectory)"/>
- <Message Text="MSBuildThisFile: $(MSBuildThisFile)"/>
- <Message Text="MSBuildThisFileDirectory: $(MSBuildThisFileDirectory)"/>
- <Message Text="MSBuildThisFileDirectoryNoRoot: $(MSBuildThisFileDirectoryNoRoot)"/>
- <Message Text="MSBuildThisFileExtension: $(MSBuildThisFileExtension)"/>
- <Message Text="MSBuildThisFileFullPath: $(MSBuildThisFileFullPath)"/>
- <Message Text="MSBuildThisFileName: $(MSBuildThisFileName)"/>
- <Message Text="MSBuildToolsPath: $(MSBuildToolsPath)"/>
- <Message Text="MSBuildToolsVersion: $(MSBuildToolsVersion)"/>
Additionally, links to the resources that dive into the details.
Hope this helps!
Posted in C#, TFS
While wrapping up my demos for my presentation “Moving WF applications to Azure”, I decided to repackage my demos using Windows Azure Accelerator to conserve the number of Web Roles I was using in Azure.
A quick summary of the issue is as follows:
- Create a Windows Azure Accelerator project, and upload it to Azure (Steps performed according to instructions provided by WAA)
- From the base address (i.e. <application>.cloudapp.net), create a IIS Site name. I just typed a random, non-active hostname for the Hostname, as I was intending to use the test link instead.
- Create a Windows WF 4.0 project, and browse to it. The generated screen with a link to the WSDL is displayed.
- Publish the WF Application to the IIS web site. It doesn’t matter if the deployment is marked as an IIS application.
- Browse to the test site where a page showing that metadata publishing is disabled. (i.e the /test/testwf/ location, rather than from the host name)
- No amount of web.config changes will enable the metadata publishing, such as an example below.
Logging onto the Azure Web Role instance revealed the following IIS setup.
I’m guessing that the test sites use URL Rewrite, but somehow the web.config is not picked up.
What finally worked for me is as follows:
- Get a DNS Alias (CNAME) to point to my base cloud application, e.g. using a free domain name from no-ip.com.
- Reconfigure WAA to accept the new Host Name
- Browse to the WF Service using the Site address instead of the test site address, and voila, the no configuration setup now works.
I hope this helps someone save a couple of hours of sleep. Now onto figuring out Azure Composite Applications.
My presentation "Moving WF Applications to Azure" to the Azure User Group Singapore (AzureUG.sg) on 29th Nov 2011 covered the following topics:
– What is Window Workflow Foundation?
– What are the features, and how does one implement them?
– Why is it relevant to applications moving into Azure?
– What are my migration / development options for using WF in Azure?
Slides have been uploaded to Slideshare: http://goo.gl/sz4IP
Demo codes have been uploaded to Azure Storage
– WFSoln: http://goo.gl/Fmsc9
– AzureWFSoln: http://goo.gl/9OXo4
[Updated] Migrations using Windows Azure Accelerator for Web Roles has been resolved. Please take a look at https://studiohub.wordpress.com/2011/12/02/migrating-wf-application-to-azure-via-windows-azure-accelerator-for-web-roles/
I recently had an experience where I had created a workflow service that was invoked using a channel factory and accepts 2 String arguments. However, after some base component refactoring, and porting the old workflow use the new components, the invocation failed with incorrect numbers of parameters.
I came across Ron Jacob’s post on making WF Services work like WCF and did a small spike project based on this blog post :http://blogs.msdn.com/b/rjacobs/archive/2010/07/30/making-a-workflowservice-work-like-a-wcf-service.aspx
|WCF Test Client Proxy
The corresponding WF Service was created, and I updated the Receive configuration to use parameters, but the behaviour did not yet match that of the WCF method.
Apparently, the Send Parameters also has to be configured so that the behaviour is consistent.
With this change on my workflow, my channel factory invocation now works again!
I was working on parsing the information from a Microsoft .Net 4.0 Workflow XAML and was stuck trying to perform an XPath query to extract out the various “State Machine State” from the XAML.
After spending some time on good old MSDN, we find the following piece of information.
With this in hand, we add a dummy namespace prefix using the XmlNamespaceManager and viola, the query now works~!
I hope this helps someone.
The Windows Azure Team has released a security refresh for the v1.3 SDK aimed to fix the issue where by the client to determine the content of the state information passed by the web role.
If you have downloaded the V1.3 SDK prior to 3 Feb 2011, perform the quick check to see if you need to have it patched.
Control Panel > Programs > Programs and Features
Scroll to Windows Azure SDK and note the version number. Anything less than 1.3.20121.1237 means that your web role(s) may be vulnerable.
Download the patch files from Microsoft (links below), and install in. Zip through the various EULA and install options. You may be prompted to shut down some services for the patch to go through.
Verify that the installation was successful (or you already have a patch SDK)
Full details and patch links available directly from Microsoft: http://blogs.msdn.com/b/windowsazure/archive/2011/02/03/windows-azure-software-development-kit-sdk-refresh-released.aspx
Posted in Window Azure