SPWakeUp (SPWakeUp3) v1.3.0 Released

SPWakeUp version 1.3.0 has been released. This version includes the ability to run on a non-SharePoint server to wake arbitrary URLs.

Use the ‘-NotASharePointServer’ command line parameter to specify that SPWakeUp should not check for the presence of SharePoint and should not attempt to evaluate a list of web applications, site collections and sub-sites.

Note: You MUST include one or both of the ‘-Include’ and ‘-IncludeFile’ command line parameters when using ‘-NotASharePointServer’ to specify a list of URLs to be woken. Failure to do so will result in SPWakeUp not attempting to wake any URLs.

SPWakeUp (SPWakeUp3) v1.2.0 Released

SPWakeUp version 1.2.0 has been released. This version includes the ability to import a list of additional URLs to be woken from a file instead of providing a series of URLs to be included individually on the command line.

Use the ‘-IncludeFile:’ command line parameter to specify the full path to the file containing URLs to be imported.

The file specified should contain a list of URLs one per line.

SPWakeUp (SPWakeUp3) v1.1.0 Released

I’ve implemented something that I’ve wanted to for a long time on SPWakeUp: The ability to wake additional URLs.

Version 1.1.0 allows the use of the ‘-Include’:’ command line parameter to specify additional URLs that will be woken once the detected site collections and subsites have been traversed.

SPWakeUp (SPWakeUp3)–Wake Up On-Premises SharePoint and WSS Instances

Since I started working with on-premises SharePoint instances, one of the solutions that I’ve used to wake up (pre-compile) the site collections and sub-sites contained within the web applications hosted by the farm is SPWakeUp.

This was originally a solution hosted on CodePlex and provided binaries for SharePoint 2007, then later SharePoint 2010 (the archive containing those can still be downloaded from the CodePlex Archive). I created compiled binaries for SharePoint 2013 and SharePoint 2016 and made those available as well.

I recently had need to use SPWakeUp on SharePoint 2019, so decided to produce a compiled for that version. As SPWakeUp doesn’t seem to have an active home anymore, I thought that it may be worthwhile putting the code and compiled versions on GitHub in case anyone else wants to use them! Note that if anyone objects to this happening, let me know and I’ll pull it down.

At the moment the repository hosts the original source code, the source code upgraded for use with Visual Studio 2019, compiled versions of SPWakeUp for SharePoint 2013, SharePoint 2016 and SharePoint 2019 and some instructions on how to compile the source yourself using Visual Studio Community 2019.

I hope it’s useful to someone!

Deploying Visual Studio 2017 Using Configuration Manager

Previous versions of Visual Studio were typically delivered via ISO files that we could import into Configuration Manager for deployment to workstations. Visual Studio 2017 arrives as a web installer only (although you can create installation media using the –layout option from the command line if you still want to go down that route).

The command-line parameters of the Visual Studio 2017 installer are also different to previous versions as well, requiring a different approach. See https://docs.microsoft.com/en-us/visualstudio/install/use-command-line-parameters-to-install-visual-studio for information on the available command-line parameters.

In the past I’ve tried using an AdminDeployment.xml file to control which components of Visual Studio are installed. With Visual Studio 2013 this worked fine for me. With Visual Studio 2015 I could not make this approach work at all, and ended up specifying the components to be installed by using the ‘/InstallSelectableItems’ command-line parameter, which worked a treat.

Visual Studio uses this latter approach to selecting the components that will be installed with the product, but the system has been extended to provide more control over the component installation, with an ‘IncludeRecommended’ and ‘IncludeOptional’ flag available for each component, or globally, as required. A list of the Visual Studio 2017 workload and component IDs can be found at https://docs.microsoft.com/en-us/visualstudio/install/workload-and-component-ids (click through to the product you’re installing, for us this was Visual Studio Enterprise 2017, workload and component IDs for which are found at https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-enterprise)

For example, to add the Azure development workload, with all optional and recommended components, you’d add the following to the command-line that you issue to the installer:

–add Microsoft.VisualStudio.Workload.Azure;includeOptional;includeRecommended

As you can see, this means that the command-line has the potential to get long very quickly!

For the workloads and components I was asked to deploy with Visual Studio Enterprise 2017, our command-line became

mu_visual_studio_enterprise_2017_x86_x64_10049783.exe –add Microsoft.VisualStudio.Workload.Azure;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Data;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.ManagedDesktop;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.ManagedGame;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.NativeCrossPlat –add Microsoft.VisualStudio.Workload.NativeDesktop –add Microsoft.VisualStudio.Workload.NativeGame –add Microsoft.VisualStudio.Workload.NativeMobile –add Microsoft.VisualStudio.Workload.NetCoreTools;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.NetCrossPlat;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.NetWeb;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Node;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Office;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Universal;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.VisualStudioExtension –add Microsoft.VisualStudio.Workload.WebCrossPlat;includeOptional;includeRecommended –add Component.GitHub.VisualStudio –add Microsoft.Component.Blend.SDK.WPF –add Microsoft.Component.HelpViewer –add Microsoft.Net.Component.3.5.DeveloperTools –add Microsoft.VisualStudio.Component.LinqToSql –add Microsoft.VisualStudio.Component.TestTools.CodedUITest –add Microsoft.VisualStudio.Component.TestTools.Core –add Microsoft.VisualStudio.Component.TestTools.FeedbackClient –add Microsoft.VisualStudio.Component.TestTools.MicrosoftTestManager –add Microsoft.VisualStudio.Component.TestTools.WebLoadTest –add Microsoft.VisualStudio.Component.TypeScript.2.0 –quiet –norestart –wait

Which, frankly, is huge!

The length of the command-line poses an immediate issue as it’s longer than that allowed in the text box for the installation program for an application. Here’s the approach I took:

  1. Once you’ve determined the workloads and components that are to be installed, create a batch file containing the command line. Prefix the command line with %~dp0 (no backslash or anything; this is to run the command-line from the current directory).
  2. (Optional) Create a batch file to uninstall Visual Studio 2017. My batch file contains the following command:
    %~dp0mu_visual_studio_enterprise_2017_x86_x64_10049783.exe uninstall –quiet –wait
  3. Copy the two batch files created, along with the web installer to a suitable location on the Configuration Manager server, the configure the application as follows:
    1. Create a new application and select ‘manually specify the application information’.
    2. Specify the name for the application, publisher, version and any other information required by your organisation:
      General Application Settings
    3. Specify the appearance of the application in the Application Catalog. Specify the icon by browsing to the web installer and selecting this. One icon is available:
      Application Icon
    4. On the ‘Deployment Type’ page of the wizard, click ‘Add’ and again specify ‘manually specify the deployment type information’.
    5. Provide a name for the deployment type, e.g. ‘Visual Studio Enterprise 2017’ and any required comments.
    6. Specify the content location. This should be the network path where the web installer and two batch files are located, e.g. ‘\SCCMApplicationsVisualStudioEnterprise2017’.
    7. For the installation program, specify the name (and extension) of the installation batch file you created earlier.
    8. For the uninstall program, specify the uninstallation batch file you created earlier, or the following command-line if you chose not to create a batch file:
      mu_visual_studio_enterprise_2017_x86_x64_10049783.exe -uninstall –quiet –wait
      Content Location and Programs
    9. Specify the detection method that you want to use. I opted for a simple ‘devenv.exe’ version greater than or equal to ‘15.0.26228.4’ which was the version of the file deployed during testing of the installer:
      App Deployment Detection
    10. Specify the user experience settings. Our installation takes approximately 60 minutes. I chose also to allow the maximum run time to be longer than the default 2 hours.
    11. Specify any requirements for the installation. I didn’t have anything to add here.
    12. Specify any dependencies for the installation. Again I didn’t have anything to add here.
    13. Complete the creation of the application by clicking ‘Next’ at the subsequent screens.
  4. Distribute the content by right-clicking the application and selecting ‘Distribute Content’.
  5. Deploy the application and select appropriate collections to deploy it to.
  6. Test!

Note: Installation takes approximately an hour on our workstations, and fails if any other Visual Studio product is running on the workstation during the installation process.

5 Tips for using Azure Web Jobs

1. Use public on the main program class.In order for web jobs to initialise correctly the main class that contains the web jobs needs to be made public. Once this has been added the individual jobs can then be read and should be visible in the output when running locally.

clip_image001

2. In order to store and view the invocation details for each web job you need to configure AzureWebJobsDashboard in the configure tab of the website you have deployed the web job to. Even if you have configured this in your app.config file.

clip_image003

If this is not configured in the website then you will receive the following error when you try and view the web jobs dashboard

clip_image002

3. Debug using Visual Studio. Once of the nice features of the web jobs SDK is the ability to run and debug the web job locally in Visual Studio. Following the Getting Started guide, you create a console application which you can debug in Visual Studio before deploying it to Azure

4. User TextWriter for debugging. The Azure Web Jobs SDK (see the logging section) provides a mechanism to log out information that can be viewed through the Azure Web jobs dashboard. By adding a TextWriter as an input parameter to your web job method, you can use WriteLine to then output information you wish to log.

5. Make your Blob Triggers more efficient by triggering them using BlobOutput. The mechanism that the BlobInput trigger uses has a 10-20 minute lag before the trigger can fire, but each time BlobOutput is used it triggers a rescan for Blob input.

“There is an optimization where any blob written via a [BlobOutput] (as opposed to being written by some external source) will optimistically check for any matching [BlobInputs],” See How does [BlobInput] work?. Storage Queues and Service Bus topics and Queues are generally processed within seconds so if you can use a queue to trigger a BlobOutput then use this to trigger any subsequent BlobInputs

Windows Azure Websites, Web API and SignalR

One of our projects involves a web service that implements both SignalR and Web API and we were looking at the quickest and most cost effective way to get it deployed so that one of our customers could run a Windows 8 application as a demo away from the office. The application works well internally as we have the service deployed on one of our servers on IIS. The options we were considering were:

  1. Package the application up in an install package, ship this to our customer and then provide them with instructions and support to allow them to deploy and configure their application
  2. Deploy it on one of our servers and then publish the service through our firewall
  3. Deploy as a Cloud service in Windows Azure
  4. Deploy as a website in Windows Azure

We considered the fact that the first option would probably take us a fair amount of time to make a deployment package, test it and provide enough documentation and support to allow our customer to deploy it on their servers. The other 3 options involved us doing a smaller amount of work, but at least we could get everything working well before shipping the demo out. Option 2 would mean using our internal resources for something that would not be used that often but we would not necessarily know whether and when it was being used so the resources would need to be kept running limiting our capacity internally. Windows Azure was a good fit for this application and the choice was really between setting up a cloud service or use a web site, I guess we could have set up a virtual machine hosted in Windows Azure, but this was a bit excessive just for a simple web service. The two remaining options were to set up a cloud service by creating a web role in deploying to Windows Azure or to use Websites. The cloud service would involve more work for us as we would need to change the project to add in the cloud service project and web role and then do a full PaaS deploy to Windows Azure. This would then utilise a whole virtual machine (although we would have used an Extra Small instance), but the web sites seem a sensible option especially as we already have a number of them available for free. How easy was this going to be and will both Web API and SignalR work with Windows Azure Websites, especially as we were using preview software. I was surprised about how easy this was to deploy and I’ll walk through the process we went through.

Step 1: Make sure that the service runs locally,

Step 2: Our service uses Code First Entity Framework using a local SQL server. Create a database using Windows Azure SQL Server via the Windows Azure Management portal (https://manage.windowsazure.com), the copy the ADO.NET connection string.

image

Paste this into your web config file of the web api service. You will need to make sure that the Windows Azure SQL Server firewall has your public IP address configured and you will need to make sure that your firewall will allow connections through port 1433. Now run your application and make sure that you can connect to the Windows Azure SQL database. As we are using Code First Entity Framework, the database tables were created for me so I didn’t need to do any database deployment. The only issue I had with this approach was that I had to create the database first in Windows Azure.

Step 3: With our service running locally but with the database in Windows Azure we are now ready to deploy to the cloud. In the Windows Azure Management portal, click the “New” button

image

The “Quick Create”, enter the url you want to use and click “Create Web Site”

image

Step 4: We now need to deploy our service. In the Azure management portal, navigate to the web site you just created and click “Download Publishing Profile”. Save this to your computer.

image

In Visual Studio 2012, open your web api project, right click on the project in Solution Explorer and click publish.

image

This will display the publish dialog.

image

Click the import button and navigate to the folder where the publish profile was saved. This should then allow you to complete the wizard

image

Click Next and check to make sure the correct connection string is displayed, click Next then Publish. This should then start to upload your web api project to the Windows Azure Website. The deploy should be relatively quick and no where near the time it takes to deploy a cloud service. When completed, your deployed website should start in the browser and you can carry out whatever tests you need.

Step 5: With your website deployed you should just need to change the url of your service in the Window 8 application.

This whole process took less than 10 minutes to setup and deploy. One of the nice features of using websites is that changes are quick to deploy.

We had a number of issues to get this all working fully:

  1. As I mentioned earlier we had to ensure that the database was created before the EF code would create the correct tables
  2. When we first ran the Windows 8 application we were getting an error each time we tried to use SignalR. We received an “Incompatible protocol version”. This was because I installed the latest SignalR libraries on the server side code but the client was using an older version. You need to make sure that both the client and server are using the same version of SignalR
  3. We also had an issue when deployed to Windows Azure where it looked like the SignalR hubs were not being created correctly. It looked like the hub creation was hanging and not returning. This is a known issue that has been fixed but not yet deployed to Azure. There is a work around which is to configure SignalR to use long polling (https://github.com/SignalR/SignalR/issues/510). We did that with the following code:
   1: hubConnection = new HubConnection(App.SignalRUrl);            

   2: proxy = App.hubConnection.CreateHubProxy("statushub");

   3: App.hubConnection.Start(new LongPollingTransport()).Wait();

Windows Azure Web Sites is not just for web sites, using it also for services can make a lot of sense as the scaling model will allow a lot of flexibility and can provide a cost effective way to host your services, especially if they are not heavily loaded at the start. They are also easy and fast to deploy which is always a bonus Smile

Publishing Windows Azure Websites with TFS

This is a follow on post from my introduction to Windows Azure Websites and shows you how you can synchronise your website in TFS with Windows Azure.

One of the biggest problems with the way you deploy applications to  Windows Azure is that minor changes (e.g .markup, content and styling) require a redeploy to publish the changes. Windows Azure Websites solves this problem by allowing you to synchronise your website with Team Foundation Server or GIT.

In this post I will show you how easy it is to manage your websites in version controlled environment using Team Foundation Service. Team Foundation Service is a cloud hosted version of Team Foundation Server.

This works by creating a continuous integration build with your source code that will automatically deploy your website after successful build each time code is checked in.

This is configured as follows:

Click the “+” button at the bottom of your portal screen and select Website –> Quick Create

image

Enter the url details and click Create Web Site

image

An Empty site has now been created.

This site now needs to be link to your Team Foundation Service. Click on the website in the dash board and then select “Setup TFS Publishing”. you will also note that you can use a GIT repository as well as TFS.

image

Enter your TFS url (or create a new one), then click Authorize Now.

image

this connects through to your TFS service and setup the CI build that will deploy your application to the cloud.

The TFS site will now be displayed asking you to authorize the connection

image

You now need to pick the website you want to deploy. If you haven’t create a site yet then you need to go to ~Visual Studio, create your site and check it in to TFS.

image

You have now linked your web site in TFS to the Azure Website. This will take a few moments to synchronise.

image

Your website has not been deployed yet. You need to make a change and then check the changes in

image

upon check-in the build is started

image

image

When the build is complete the new website is deployed

image

image

You can also revert back to older versions of the web site by clicking the desired version and then clicking redeploy:

image

This will start the redeploy of the older version:

image

A new build is kicked off using the same changeset details as the original deployment. Once the build is complete the  web site is reverted back. this whole cycle only took a few minutes so it is a lot faster than the redeploy mechanism you had previously.

image

image

TFS and Windows Azure provide a good mechanism for version controlling your website. Adding application life cycle management to any software development activity is a good thing.

Deploying Windows Azure Toolkit For Windows 8 Notification Service to the Cloud

If you have installed the Window Azure Toolkit For Windows 8 you may want to deploy it to a real live environment so that you can try out the notification service and start wiring useful Windows 8 applications. I assumed this was going to be a quick task, but it took me a little longer than expected. Firstly when you try and deploy the web application and service to Windows Azure it won’t just deploy out of the box. You need to sort out the certificates for SSL, Out of the box the certificates come as a cer file and Windows Azure only accepts pfx file so you will need to convert the file.  I set up the certificate and deployed to Azure but when I connected my windows 8 application to register for notifications I kept getting errors connecting to my registration service. After a number of attempts to connect I determined that it was an issue with the certificates. The Windows 8 application has an appmanifest file which contains the certificate information. I set this up as I thought was correct but I still could not get the application to talk to my Azure service. Running in the debugger didn’t seem to give me any error diagnostics. Eventually I found this article which provided me with a bit more detail as to what was required (I was doing most of what was suggested). A number of additional issues arose which slowed me down a bit further.

1. When creating a new certificate I needed to run the command prompt as administrator. On my computer my user account is not an administrator so when I created a new certificate. In order to export the certificate I needed to run the certmgr as administrator.

2. Selecting the certificate in Visual Studio to assign to the endpoint was also an issue as it is deployed as administrator so it didn’t seem to appear in the list. I found the certificate and then copied its thumbprint (converted it to uppercase letters) and pasted it into the thumbprint field in the certificate in the role properties.

The Azure application was then deployed to Azure and the new certificate added to the Windows 8 client as per the instructions in the article above.

You should now be able to login, upload images and send notifications.

Now that’s working I can start to build a proper notification service.