Visual Studio & Node JS

When you install Visual Studio 2017 it very kindly gives you the option to install Node.js

The only problem with this is that if you are not using v15.3 (or greater) of VS2017 then working with Azure Functions can present a couple of unusal issues.

  • Not being able to install the Azure Client Tools.
  • My application not being able to read from the local.settings.json file using the WebConfigurationManager.

The problem turned out to be the version of Node.js that was installed with Visual Studio and that I needed to update it to a more recent version. After completing the updated installation I was able to install the Azure tools and successfully read values from my local.settings.json file in my local development environment.


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.


D365 Portal – Cache Tool

The D365 Portal needs to be configured to automate the clearing of the cache within the Portal for data that is modified in D365. As a Portal Administrator you can access a hidden portal page, once you have logged in, to manually clear the cache. After logging in, navigate to <portal url>/_services/about. On the page, in addition to some details about your portal is a Clear Cache button which forces the portal cache to be refreshed.

Microsoft.Dynamics.CRM.Between Dates

A quick example of using the Between function for the Dynamics 365 Web API.

$filter=Microsoft.Dynamics.CRM.Between(PropertyName='createdon',PropertyValues=["2017-01-01T00:00:01Z","2017-04-30T23:59:00Z"]) and statecode eq 0
  • The dates need to be defined in UTC format to ensure quality of the data returned. It can be specified as “mm/dd/yyy” but this may be confusing if you are operating in non-US date formats.
  • The Functions can be combined with your other standard filters e.g. statecode eq 0.

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

CSOM – ContentType and CAML Queries

To retrieve the ContentType of a ListItem from the ListItemCollection using the GetItems method, there are two approaches that work.

  1. If you are not specifying ViewFields in your CAML query then in your Load method you need to Include the ContentType. e.g.

clientContext.Load(listItems, items => items.Include(item => item.ContentType));

  1. If you CAML query includes ViewFields then two modifications are required. The ViewFields needs to include the ContentTypeId field and the Load method needs to include the ContentType. e.g.
<ViewFields><FieldRef Name='ContentTypeId' /></ViewFields>

clientContext.Load(listItems, items => items.Include(item => item.ContentType));