Azure func and Visual Studio

I had been running my Azure Functions locally to debug the processes when this morning the func.exe kept failing each time I pressed F5 and would not allow me to debug my code. The Storage Emulator on my machine was started and I could access it through the Storage Explorer and my application Properties were correct but func.exe would not fire up.

After a bit of head scratching I decided to fire up the func.exe outside of Visual Studio and run it against my project and func gave me the answer straight away.

I had been playing around with my local.settings.json and the entry for AzureWebJobsStorage was empty. Because the func.exe shuts down straight away when running in Visual Studio I wasn’t able to see the error but I could when I ran it outside of the IDE.


VSTS – Package Manager with NuGet (Part 2)

Having successfully added NuGet pack  and  push tasks to my Build within VSTS, the next task was to separate out the push from the Build and use it within a Release. The main reason for this is to provide greater control over when a package is pushed to the VSTS package manager rather than after each build.

The first modification is to the Build definition to remove the NuGet push task. Next, I created a new Release definition with a single environment I called Package Manager. The Release definition contained one task and that was the NuGet push command. Since we had already created the package as part of the Build, the path to the NuGet package(s) to publish is available for us to select.


Two points worth mentioning here.

  • The path uses *.nupkg to ensure the Release picks up the latest build of the package and not a specific version.
  • The path, …/Model-Packaged/… is an Artifact source alias defined in the Artifacts tab.
  • artifacts-source-alias

Once the Release environment has been created with the Push task pointing to our pre-existing Target feed we can create a release which will pick up the current NuGet package generated during the Build and push it into the feed in the Package Manager. One other point to remember is that the push will fail if you try to upload a package to feed with the same version number as the current package.


VSTS – Package Manager with NuGet

As our project has grown we have identified a number of occurrences where the same assembly is being used across a number of different branches. To improve the management of this single assembly I have been using the VSTS Package Manger to create a NuGet package that we can consume within these projects. This post is about my experience of using PM for the first time and some of the things I learned along the way. At the bottom of the post are links to URLs that I used to help me.

You can create a NuGet package on your machine using the NuGet CLI and upload it to the Package Manager manually. This is a good place to start if you want to get something into the PM and see how it looks when you pull down the package in Visual Studio etc. I found using the NuGet CLI to create the .nupkg file helped me to understand what would be required to make it part of a CI build. The NuGet CLI and VSTS NuGet Task allow you to build from either a .csproj (.vbproj) or .nuspec file. To create a .nuspec file for your project use the NuGet CLI with the spec command. The .nuspec file allows you to set the metadata for your project and include replacement tokens that can be substituted from the CLI. After creating my basic .nuspec file I can then run the following NuGet command to create my first package.

nuget pack MyCompany.MyProject.csproj -Build -Properties configuration=debug;description=My first NuGet Package;author=MyCompany -Verbosity Detailed

The -Properties argument defines what replacement tokens are substituted in the .nuspec file. If your project has an AssemblyInfo file but does not contain an entry for AssemblyCompany or AssemblyDescription you must provide these in the command line or the pack command will fail. (See the Replacement Tokens section for more information). The configuration=debug defines which project configuration will be built with the -Build flag. QUICK TIP – if you run the NuGet commands in PowerShell you need to escape the semi-colons using the opening single quote character (`).

The version number of your .nupkg will be taken from the AssemblyInformationalVersion (if available) or the AssemblyVersion entry within the AssemblyInfo file. If you are using a SharedAssemblyInfoFile (SolutionAssemblyInfoFile) to store common values then these need to be defined in the NuGet pack command -Properties as version=x.x.x.x or using the -Version argument.

At this point you can upload the completed package to the Package Manager following the instructions available here. Having created a .nupkg on my own machine the next  stage was to do this as a task of a build process. The current documentation of creating NuGet Packages during the build is a little out of date at the time of writing this article as it refers to the deprecated NuGet Packager task, however there is now a single NuGet task with the different NuGet commands as an option. When I first tried the NuGet build task the problem was making sure that the NuGet task could find the files to include in the .nupkg. To solve this problem I had to make sure the Visual Studio build task, for the .csproj, placed the files in the right location. This was achieved by adding the following MSBuild Argument /p:OutputPath=$(Build.SourcesDirectory)\MyCompany.MyProject\bin\$(BuildConfiguration) .

The .nuspec file included the source control ensures that common settings for the .nupkg are retained for each build. The NuGet Pack task allows for the setting of Pack Options for versioning, however for my build I set this to off and used the used the version specified in by the AssemblyInformationalVersion. I also specified some additional build properties (-Properties attribute) in the Advanced section.

Once the package has been created as part of the build the next stage is to include the NuGet push command task. Again, the current documentation is a little out of date as it refers to the deprecated NuGet Publisher task. To publish the package use the same NuGet task as before but this time selecting the push command. Since we have already created the Package Manager feed we just need to select this as the Target Feed in the push task. Having completed the NuGet push task, the process now has all the tasks to build the project, create a NuGet package and send it to our Package Manager. Finally, we can access the .nupkg from within Visual Studio.

URLs I have found useful on this journey

Oracle Java JDK – A more recent version of this software is required

I had previously installed Visual Studio 2015 Community Edition to do some Cordova development but was getting this message;

Oracle Java SDK A more recent version of this software is required

I downloaded the updated JDK but it wasn’t being recognised in my system. Information about this can be found here –

If you modify any of the tools you are using then you need to ensure that your Environment Variables are configured correctly. A list of these variables are available here –

I chose to override the JAVA_HOME environment variable, instead of modifying them in the Computer Control Panel, to the latest version of the JDK I had installed – C:\Program Files (x86)\Java\jdk1.8.0_45. This resolved the issue for me.

ASP.NET Web API, ELMAH and Folder Permissions

This post just covers a few useful things I have found while I have been developing an ASP.NET Web API that uses AttributeRouting for Web API and ELMAH for Web API.

I found AttributeRouting much easier to configure and administer than using MapHttpRoute in the WebApiConfig.cs file; especially using the RoutePrefix at the controller level. Running tests on the attributes using the Route.axd was also very straight forward. I also found Fiddler (v4.4.8.0) to be very helpful in throwing different unit tests at my newly created web API. This is simple and powerful configuration that works straight out of the box.

Using the Elmah.Contrib.WebApi took a little more configuring to get working but I found a good place to start, after you had installed the NuGet packge was on the sample web.config page. This provides detailed examples of the configuration settings needed for the different types of log stores as well the basic settings for the different flavours of IIS. There were a couple of additional tweaks I would recommend:

  1. Since I am not generating any View I removed the filters.Add(new HandleErrorAttribute()); in the FilterConfig. The HandleErrorAttribute to serve up a View called Error. Since this is a Web API project and I don’t have any Views then it wasn’t needed.
  2. Instead, there is a rather neat process for capturing unhandled errors that I found here.
  3. Finally, if you are using a simple XML file to store your errors you need to make sure that the security configuration is correct for the folder where the files will be generated and stored. For example, I had my files stored in the App_Data folder under the root of the web site on IIS 7.5. The application pool for this site was running under the ApplicationPoolIdentity account and so this account needed to have write permissions to the App_Data folder. Instructions for doing this can be found here under the Securing Resources section of the article.


Visual Studio 2013 and Visual Studio Online

When I first saw Visual Studio online being advertised I didn’t think it would be something I would use that much. However, in the process of creating a Windows Phone application I was reading about the availability of Team Foundation Server as part of the VS Online package. Since I was creating my application in VS 2013 on my machines at home it was great to find out that I could have my very own TFS setup in the cloud; not only that but its also FREE for the first five users. This allows me to have the useful features of TFS and know that my code follows me where ever I happen to be developing.

I still prefer my ‘on machine’ IDE for doing my development and doing it on my Surface 2 Pro has proved to be very effective. The performance of the machine is fantastic and with the all day battery life I can do as full days work on a single charge. The backlit keyboard on the Type 2 cover also helps when you have ideas in the middle of the night!

COM references in Visual Studio and RegSvr32

I was trying to add a new COM DLL to my VS2010 project but it kept giving me the following error message:

A reference to the “….dll” could not be added.Please make sure that the file is accessible and that it is a valid assembly or COM component

Then I realised I hadn’t registered my self-registering assembly on my machine as this was a new machine and the first time I had used this project. Since I had my VS Command Prompt open I ran RegSvr32 on the assembly and waited for the usual message. Instead it threw me an error and I was left to try and find out what was causing the problem. As it turns out the solution was relatively simple. I needed to run my command prompt as the administrator to get RegSvr32 to work as I am using a Windows 7 OS. Now my COM DLL is registered and listed in the COM tab of the Visual Studio Add Reference dialog.