I recently worked on a project for a client which the deployment environment was only to have .NET 2.0 installed. This is a rarity these days, after all .NET 3.5 was released in November 2007 (http://en.wikipedia.org/wiki/.NET_Framework#.NET_Framework_3.5), so having chosen to not install it is a bit of an effort.

But fine, what ever floats your boat I guess, but there is a problem, pretty much all the libraries which we’ve developed at The FARM are .NET 3.5 libraries, generally because they use features like LINQ or Extension Methods.
Damn, that’s going to be a pain in the ass, I’d either have to forgo our libraries, or make custom versions of them.

Or, I could be a bit ninja-esq and make a .NET 2.0 website, which has .NET 3.5 assemblies in it, now that sounds like fun.

But let’s step back a bit, what is .NET 3.5 in relation to .NET 2.0?
Well really .NET 3.5 is a super-set of the .NET 2.0 framework (well, technically a super-set of .NET 3.0, which itself was a super-set of .NET 2.0, but you get the idea). But why is that? Well .NET 3.5 is built on top of the same CLR (Common Language Runtime) which powers .NET 2.0.

Since most people associate .NET 3.5 with Visual Studio 2008 so I’ll talk about them in a combined manner.

In addition to the .NET 3.5 release we also received the C# 3 compiler. This nifty little bugger brought along the translation of => to being either a Func, Action or Predicate, and it also introduced the var keyword.
But the fun thing is that because C# 3 is targeted at the 2.0 CLR all the compiled IL is perfectly valid for .NET 2.0! This is actually how (and why) multi-targeting in Visual Studio 2008 works (well, how and why at a very high level :P) and why you can use var, lambda, etc in a .NET 2.0 project provided it’s made in Visual Studio 2008.

But back to our original topic, how do I use .NET 3.5 without installing it on the server? (Note – you’ll still need it installed on the dev environment)

Putting the pieces together

So we’ll create a new ASP.NET web application, still choosing .NET 3.5 as the framework version and do everything as per normal. The tricky part is when we come to wanting to deploy the site onto our target environment, which doesn’t have .NET 3.5 installed.
Before we can do this there is one last thing we need to change within Visual Studio, you need to change the way the Visual Studio handles the referenced assemblies. Framework assemblies (well, any assembly which is in the Global Assembly Cache (GAC)) are set to Copy Local=False, you need to change this to True, so right-click the assembly and go to Properties:

Now what will happen is that when the compile is done the assembly/ assemblies will be copied into the /bin folder of your site, meaning now they are loaded into memory, but not loaded there from the GAC!

You can then take all the files and deploy them to the target environment, with the .NET 3.5 assemblies in the /bin folder, but not installed.

Really a great trick with Shared Hosting ;)

Come on down to TheFARM to share in some beers and take part in the global Umbraco 5^th birthday festivities.

Your hosts will be core Umbraco team developers Shannon Deminick & Aaron Powell, both of whom work for TheFARM (http://www.thefarmdigital.com.au).

The plan is for Shan and Aaron to run a Q&A session with some demo’s of the fun stuff TheFARM has been doing with Umbraco 4.1 and the work they have been doing on this next release.

• They'll have a look at all of the new features/fixes for 4.1 (are there are TONS)
• They'll go into a bit more in detail on some of the new things that we've integrated into the core such as LINQ to Umbraco, Umbraco Examine, new controls, enhancements, preview, etc…
• They’ll show you some of the sites we’ve built and talk through some of the implementation’s with things like Flash

Hopefully, with two of the core team on hand we should be able to answer most questions thrown at us – give us a go!

Once we're out of beers... TO THE PUB!

All of the details, address, etc.. is on the Our Umbraco website. Have a look and RSVP now!

http://our.umbraco.org/events/umbraco-5th-birthday-meetup-in-sydney

 

Just in case you don’t want to click through here’s the event details:

Tuesday, February 16, 2010 - 6:00 PM
Suite 101, 4 - 14 Buckingham st Surry Hills, NSW

In a previous post Shannon explained how to customise TinyMCE for what HTML elements Flash actually supports, and he finished off the post with showing how to cleanup line breaks.

To do this he used an XSLT function called normalize-space, which is great if you’re using XSLT!

I was writing a service today which was using LINQ to XML to generate the XML for Flash, but that posed a problem, how do you deal with Flash wanting to do hard breaks on new line constants?

Easy, string.Replace to the rescue!

Here’s a handy little extension method you can drop into your code libraries:

public static string NormalizeSpace(this string s) {
	if(s == null) throw new ArgumentNullException("s");
	return s.Replace("\r\n", string.Empty)
		.Replace("\r", string.Empty)
		.Replace("\n", string.Empty);
}

Nice and easy (and unsurprisingly logical!).

Currently the codebase in Umbraco 4.0.x uses quite a few iframes to render ‘controls’ as this functionality has existed this way from way back in the day and had never been upgraded… until now!

IFrames should be used sparingly, they have their uses but to render an iframe instead of a User Control is just adding overhead to the page, the client and server cpu/memory consumption and is not so cool. Here’s a nice benchmark on iframe performance: http://www.stevesouders.com/blog/2009/06/03/using-iframes-sparingly/ . As you can see, you should use iframes ONLY when completely necessary.

So on to the good news… Here’s some new controls that have been created in 4.1 (which will remove many of these iframes and make things a whole lot nicer to use)

• /umbraco/controls/Tree/TreeControl.ascx
  • Will render a new tree based on the properties set
  • This makes the following Obsolete: treeInit.aspx, treePicker.aspx  (though, these pages are still used to load trees in modal windows for pickers but shouldn’t be used directly in your code)
    • Both of these pages now simply wrap the TreeControl
  • Example usage:
    

    <umb2:Tree runat="server" ID="DialogTree" 
        App="media" TreeType="media" IsDialog="true" 
        CustomContainerId="TinyMCEInsertImageTree" ShowContextMenu="false" 
        DialogMode="id" FunctionToCall="dialogHandler" />

    
    
  • There’s quite a few other properties that allow you to customize the tree to your needs
  • There’s also a very in-depth JavaScript API
• /umbraco/controls/Images/ImageViewer.ascx
  • This is a nifty ajax control that will take a media item id and display the image
  • There’s a simple JavaScript library attached to it that allows you to dynamically update the media id to force an ajax request to refresh the image (amongst other methods)
  • This makes the following Obsolete: /umbraco/dialogs/imageViewer.aspx
    • The old codebase for imageViewer has been retained (though it should probably just wrap this control :)
  • Example usage:
    

    <umb3:Image runat="server" ID="ImageViewer" 
        ViewerStyle="ThumbnailPreview" LinkTarget="_blank" 
        ClientCallbackMethod="onImageLoaded" />

    
    
• /umbraco/controls/UploadMediaImage.ascx
  • This control is essentially what you see when you load up TinyMCE, select the insert image button, then click on the ‘Create New’ tab. It contains the logic to enter a name, select a file to upload and select the media tree node to upload it to.
  • There’s a handy JavaScript callback method you can define so that it’s executed once the upload is complete. Tons of parameters are passed to the callback containing all of the information about the file/image.
  • This makes the following Obsolete: /umbraco/dialog/uploadImage.aspx
  • Example usage:
    

    <umb4:MediaUpload runat="server" ID="MediaUploader" 
        OnClientUpload="onFileUploaded" />

    
    

Now, on to the ‘pickers’! There’s quite a few picker controls in the codebase that all essentially do the same thing but the code for them was pretty much replicated everywhere, so i decided to streamline the whole thing which should make it quite easy for anyone to make their own pickers!

• umbraco.controls.BaseTreePicker.BaseTreePicker (in the umbraco.controls assembly)
  • (yes i know the namespace and control are the same name, but that’s the way it is currently! :)
  • From the name, you would probably determine that this control is an abstract control… and you’d be correct.
  • This control implements: IDataEditor (so that it can be used as the data editor for Umbraco data type controls), and INamingContainer for obvious reasons.
  • This control exposes many properties and methods for you to modify and override to customize the picker.
  • The abstract properties are ModalWindowTitle (the title of the window that gets displayed) and TreePickerUrl (the URL to load in the modal window that is displayed)
  • This pretty much handles everything for a basic tree picker and the JavaScript has been refined to use real classes! Wow! ;)
• umbraco.editorControls.mediaChooser (in the umbraco.editorControls assembly)
  • This is the umbraco data type to select a media item from the media tree
  • It’s been upgraded to inherit from BaseTreePicker and overrides the JavaScript rendered to support Tim’s new fandangled media picker (similar to the TinyMCE media picker)
• umbraco.editorControls.pagePicker (in the umbraco.editorControls assembly)
  • This is the umbraco data type to select a content node from the content tree
  • It’s been upgraded to inherit from BaseTreePicker … it really doesn’t have any special functionality apart from setting the title and the tree picker url since all of the required functionality is in the BaseTreePicker
• umbraco.controls.ContentPicker (in the umbraco assembly)
  • This pretty much does the same thing as all of the above controls, actually it’s nearly identical to the pagePicker only you have to specify the AppAlias and TreeAlias to load for the picker.
  • It’s been upgraded to inherit from BaseTreePicker also

So basically, everything will look pretty much the same, but will be a lot faster and MUCH easier to develop with if you’re creating custom packages or whatever. It’s all backwards compatible (apart from the JavaScripting) but under the hood is much different.

So now at least when you load up the TinyMCE insert image dialog, you end up with 1 frame (the modal dialog) instead of 4!

Oh yeah, and this hasn’t been checked in to the 4.1 branch as of today… perhaps next week!

Last year there was an article posted on TechChrunch about the problem of deploying your .snv folder live, it’s a really great way to give everyone your websites source code!

Recently though while tweaking our 2 Click ASP.NET Web Application Deployment with MSBuild to include a static folder consisting of the umbraco/ umbraco_client folders (which we leave excluded from the project to ensure performance of Visual Studio) I noticed that we were including the .svn folders!

We’re generating an ItemGroup like this:

<ItemGroup>
  <Umbraco Include="$(LocationWorkingWeb)\umbraco\**\*.*"/>
  <UmbracoClient Include="$(LocationWorkingWeb)\umbraco_client\**\*.*"/>
</ItemGroup>

Which recursively adds the files from those folder, including .svn.

Balls!

Sure it’s not really a problem, we’ve got no source code stored in those folders (and anyone who is putting their own source in umbraco or umbraco_client is asking for trouble), but by including them you’re pretty much doubling the size of the folder structure too!

Luckily it’s quite easy to solve. MSBuild has a build-in Exclude attribute, so you just need to change it to look like this:

<ItemGroup>
  <Umbraco Include="$(LocationWorkingWeb)\umbraco\**\*.*" Exclude="$(LocationWorkingWeb)\umbraco\**\.svn\**\*" />
  <UmbracoClient Include="$(LocationWorkingWeb)\umbraco_client\**\*.*" Exclude="$(LocationWorkingWeb)\umbraco_client\**\.svn\**\*" />
</ItemGroup>

It looks a bit weird, you’ve got to recursively exclude the recursive contents of the .svn folder :P

It’s all about making sure you only deploy what you should have on a production server, and it goes in hand with remembering that PDB != Product Deployable Bits.

Flash doesn’t support most of the html elements of a standard web page. TinyMCE’s creators Moxiecode have thankfully given us the TinyMCE rules for flash here:

http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements#Full_FlashMX_2004_rule_set:

So to get Umbraco & TinyMCE working to give your flash application the markup that it needs you need to modify your \config\tinyMceConfig.config file:

<validElements>
    <![CDATA[+a[href|target],
+b,
+br,
+font[color|face|size],
+img[src|id|width|height|align|hspace|vspace],
+i,
+li,
+p[align|class],
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+span[class],
+textformat[blockindent|indent|leading|leftmargin|rightmargin|tabstops],
+u
]]>
</validElements>

Then there’s the issue that flash treats real line breaks and <br/> tags exactly the same! This will probably cause you a few headaches trying to work that out. So to save you that headache, you need to output the rich text markup via XSLT to flash using the XSLT function: normalize-space

Something like:

<xsl:value-of select="normalize-space($myRichTextValue)" />

Today we had a mini site which the promotion had completed, but the site was to stay live with a few of the content pages staying live for people who come to view it.

Because the site was only a few pages there isn’t a CMS back-end, it’s just flat ASPX pages are stored in a single folder.
The problem is, that the pages which need to be available are also in the folder which the pages which are not longer accessible are.

There is a few ways in which I can take down the pages which people aren’t meant to access, firstly I could just delete them. That’d work, but that’d be a 404 error which isn’t really a good user experience (I could set the 404 redirect to be the home page, but the browser would still receive a 404 HTTP status).

So the next option is URL Redirection, lets crack out our UrlRewriting.config file and set up a rule. We’ll start with a rule like this:

<add name="RedirAllIndexedPagesToDefault" virtualURL="^(.*)/pages/(.*)" destinationUrl="$1/default.aspx" redirectMode="Permanent" redirect="Domain" ignoreCase="true" />

There, that’ll handle everything in our pages folder, but it doesn’t help with the pages which I want accessible. Say the pages I want accessible are TermsAndConditions.aspx and PrivacyPolicy.aspx, but I don’t want Entry.aspx accessible.
It’s just a matter of modifying my virtualURL to be a bit stricter, so now it looks like this:

<add name="RedirAllIndexedPagesToDefault" virtualURL="^(.*)/pages/(?![TP.*])(.*)" destinationUrl="$1/default.aspx" redirectMode="Permanent" redirect="Domain" ignoreCase="true" />

Now you’ll not be able to get to Entry.aspx, but the other two pages will still work just fine.

Sure it’s not great if you’ve got lots of pages (and if you did have lots of pages I’d hope there was a CMS to deal with it), but it’s good for mini sites which you want some pages but not others in a folder accessible.

Here’s a quick little snippet of how to check if one of your objects implements a specific interface. I’m not sure if there’s a ‘better’, or more efficient way to do this but I’ve been using this method to do this check for quite some time:

if (typeof(IMyInterface).IsAssignableFrom(myObject.GetType()))
{
	//Do stuff...
}

UPDATE:

Turns out there is a way easier and probably much more efficient way of doing this! I just didn't know it worked with interfaces too

if (myObject is IMyInterface) { //Do Stuff.. }

Much nicer!

After foolishly pulling out my hair trying to find out why my wildcard mapping was disappearing in IIS 7 using classic pipeline mode, i realized it was my own fault!! I followed the instructions on this site: http://learn.iis.net/page.aspx/508/wildcard-script-mapping-and-iis-7-integrated-pipeline/ and unfortunately just skipped over the message about how this modifies your web.config… oops! So basically, every time I deployed my handler mapping would be removed… Doh!

Unfortunately, the method to add a wildcard mapping in this article will actually remove the inheritance of standard handlers from the root of IIS and your machine.config and just make copies of them. This might not be the best approach, but i suppose sometimes it’s necessary. We only need the wildcard mapping for URL Rewriting so i decided to see if i could just simply add the isapi wildcard mapping only, have the rest of the handlers inherit from the root and see if it works… turns out it does!

So instead of having to modify IIS itself, i just needed to add this to my web.config:

<handlers>
	<remove name="ASP.Net-ISAPI-Wildcard" />
	<add name="ASP.Net-ISAPI-Wildcard" path="*"
	verb="*" type="" modules="IsapiModule"
	scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll"
	resourceType="Unspecified"
	requireAccess="None"
	allowPathInfo="false"
	preCondition="classicMode,runtimeVersionv2.0,bitness64"
	responseBufferLimit="4194304" />
</handlers>

Too easy! No fussing around with IIS and now at least i won’t override my changes accidentally.

A couple of months ago Shannon wrote a post on how we do 2 Click Deployments at The Farm (if you haven’t read this post I suggest you read it first as I make the assumption it’s been read and skip over a few sections that it covers). I’ve been working with him to try and improve our process of deployment, and one of those tasks has been moving away from using NAnt as the build runner to using MSBuild.

Why the shift? Well MSBuild has actually come a long way recently and despite common belief it’s not just for building .NET applications. In fact it can be used the same way that NAnt can be used, to execute arbitrary operations.
As mentioned in the original post we’ve used an internal tool for modifying the web.config (and other configuration files) but it had a bit a limitation as it meant that the files were always full of settings for all environments. It also wasn’t designed to update a single property of an XML node, you’d need to replicate the whole XML structure, even if it was just 1 attribute changing.

So I suggested that we migrate to a XSLT based config management, which is what I’d used previously. A former colleague of mine has a good post on how to set that up, it can be found here.

Moving to MSBuild also brought in another advantage, it would simplify our deployment process. Currently we’re using CruiseControl.NET to execute a NAnt script which in turn executed MSBuild.

Another goal was to allow us to deploy from the branch in source control, rather than from the trunk, this way you can deploy different branches if you want to test different functionality based on a branch without overriding the trunk. So we’ve updated our source control structure to look like this:

• trunk
• branch
  • v1.1
  • …
• build

The new addition is the build folder, this folder will generally only hold a single file, and that’s the master build information, which we’ll call cc.build. This build file is the one that CruiseControl.NET will look for and check out. It then contains the instructions to which branch to check out, and then handle the rest of the execution of the build. A sample looks like this:

<Project ToolsVersion="3.5" DefaultTargets="CheckoutAndBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>

  <PropertyGroup>
    <BranchVersion>v1.1_net</BranchVersion>
    <BuildType>_net</BuildType>
    <BranchFolder>$(BaseFolder)\$(BuildType)</BranchFolder>
    <RepoPath>file:///\svn/Client/branches/$(BranchVersion)</RepoPath>
  </PropertyGroup>

  <Target Name="CheckoutAndBuild">
    <RemoveDir Directories="$(BranchFolder)" />

    <SvnCheckout RepositoryPath="$(RepoPath)"
					LocalPath="$(BranchFolder)"
					ToolPath="C:\Program Files\CollabNet Subversion">
      <Output TaskParameter="Revision" PropertyName="Revision" />
    </SvnCheckout>

    <Message Text="Revision: $(Revision)"/>

    <Time Format="yyyyMMddtt">
      <Output TaskParameter="FormattedTime" PropertyName="buildDate" />
    </Time>

    <MSBuild Projects="$(BranchFolder)\cc.msbuild"
             Properties="CCNetWorkingDirectory=$(BaseFolder);BuildDate=$(BuildDate);DeployType=Dev;DeployLocation=$(BaseFolder)..\Deployment\Dev;BuildConfiguration=Debug;ShowMessages=True;IncludeSymbols=True" />
  </Target>

</Project>

So lets have a look at the break down of this file. First off, we’re using the MSBuild Community Tasks for tasks such as the SVN checkout, and a few other aspects which we’ll cover later.

When we call this MSBuild file from CruiseControl.NET and pass in a parameter, BaseFolder, which is the Working folder (see the Folder Structure section of the original post).
There’s some parameters combined so we get a path to where we’ll be checking out the branch, etc.

First thing is to remove any existing checkout folder, and then have SVN checkout the latest copy of the branch.
As Shannon mentioned in the original post we timestamp each sip package, so for this we’re using the Community Task date formatter to generate our timestamp.

Then it gets a bit tricky, because this file is a dumb file and doesn’t know what’s going to be done by the branch deployment file so we need to have a way in which we can actually do a build. This is done by using the MSBuild task which allows you to execute any specified MSBuild file(s). This is done by passing the file to execute into the Projects attribute. Since we’re going to execute the one within the branch we tell it to look there.
Then it’s just a matter of passing any properties you require into the MSBuild file, here we’ve got a bunch of different parameters which the target file can consume.

The MSBuild task is then replicated as many times for each different environment/ location which you want to build for.

 

Each branch maintains its own msbuild file, which is also called cc.msbuild so that we can keep the naming consistent across all locations. This file is the one which is responsible for:

• Compiling the project
• Modifying the config files
• Zipping the release

But this can easily be expanded upon, depending how the branch needs to be handled, there’s nothing that says it couldn’t also do the copying to the appropriate server, etc. Lets take a look inside this file.

<Project ToolsVersion="3.5" DefaultTargets="ZipFiles" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>

  <PropertyGroup>
    <LocationWorkingWeb>$(CCNetWorkingDirectory)\_net\Client.Web</LocationWorkingWeb>
    <ProjectWeb>$(LocationWorkingWeb)\Client.Web.csproj</ProjectWeb>
    <BuildFolder>$(DeployLocation)\$(BuildDate)\</BuildFolder>
  </PropertyGroup>

  <Target Name="ZipFiles" DependsOnTargets="FormatFiles">
    <ItemGroup>
      <ZipFiles Include="$(BuildFolder)**\*.*" Condition="$(IncludeSymbols) == 'True'" />
      <ZipFiles Include="$(BuildFolder)**\*.*" Exclude="$(BuildFolder)**\*.pdb" Condition="$(IncludeSymbols) == 'False'" />
    </ItemGroup>

    <Zip Files="@(ZipFiles)"
         ZipFileName="$(DeployLocation)\$(BuildDate).zip"
         WorkingDirectory="$(BuildFolder)"/>

    <RemoveDir Directories="$(BuildFolder)" />
  </Target>

  <Target Name="FormatFiles" DependsOnTargets="BuildWebProject">
    <MSBuild Projects="transformers.msbuild"
             Properties="XslFile=$(CCNetWorkingDirectory)\_net\CruiseControl\Web.config.xslt;OutputFile=$(BuildFolder)Web.config;InputFile=$(LocationWorkingWeb)\Web.config;Environment=$(DeployType)" />
  </Target>

  <Target Name="BuildWebProject">
    <MSBuild Projects="$(ProjectWeb)"
             Properties="Configuration=$(BuildConfiguration);OutDir=$(BuildFolder)bin\;WebProjectOutputDir=$(BuildFolder)"
             Targets="Clean;Build;ResolveReferences;_CopyWebApplication"/>
  </Target>
</Project>

This file, again uses the MSBuild Community Tasks, but its also a whole lot smarter about what’s happening for this particular build. I’ve specified that the DefaultTargets of the file is the ZipFiles which is really the final task which I want to execute.
One really nice thing about MSBuild is that you can specify a DependsOnTargets attribute for a target, which states that the particular target(s) must have executed before the called one will execute. So by looking at how the dependency is configured the project will have been compiled and the files formatted will both have been done. Makes it so much simpler to execute something, rather than having a ‘runner’ target which is just responsible for calling a bunch of targets in order we can just have them done in order of dependency.

So we’ve got a BuildWebProject target which will again call an external MSBuild file, in this case our csproj file, passing in some of the information which was given to us from the ‘master’ file, in a manner in which Visual Studio itself would have done.

Next we format the files. This goes off to an external MSBuild file, so we can use the same operations for every single file we want to format. The contents of transformers.msbuild is as follows:

<!-- ROBOTS IN DISGUISE -->
<Project ToolsVersion="3.5" DefaultTargets="Xslt" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>
  <ItemGroup>
    <XslFileWithParams Include="$(XslFile)">
      <environment>$(Environment)</environment>
    </XslFileWithParams>
  </ItemGroup>
  <Target Name="Xslt">
    <Xslt RootTag="" Inputs="$(InputFile)" Output="$(OutputFile)" Xsl="@(XslFileWithParams)" />
  </Target>
</Project>

This is a basic task file which adds a parameter (named envrionments) to our XSLT and then uses the MSBuild Community Tasks to do the transformation.
Note – this is a slight deviation from Alistair’s blog post, we don’t have a different XSLT per machine, we have a single XSLT which we use the parameter to determine what to do. This makes it easier to see all the options we want to change per environment.

Lastly the dependencies hierarchy throws us back to the ZipFiles target, where we gather all the files together that we want (and there’s an option to exclude the pdb files, after all PDB != Product Deployable Bits ;) ), call the Zip task (make sure you specify a working folder otherwise you’ll end up with a crazy hierarchy in the Zip!) and then we delete the folder which we built to.

 

Conclusion

MSBuild is a good tool which can be used for doing operations other than just compiling a .NET project, as you can see here we’re using it to pull files down out of SVN or transform a file via XSLT. This doesn’t have anything to do with compilation, or .NET for that matter.

It make take a bit of work to get set up, there was quit a bit of frustration vented during this process but now that it’s working there’s no looking back.