Wow what a title, but it does explain that this post covers debugging the full .net framework application (not .net core) running on a Server Core container (not Linux) from the comfort of a Windows 10 Pro machine running Visual Studio 2015 and Docker for Windows.

Running remote tools on a machine and attaching is a pretty straight forward task, but there a re a few hurdles in the way when doing it on Windows Server Core 2016 container, but once it is scripted it is pretty painless.

Firstly we need a decent Docker image to start with, luckily the guys at Microsoft have created the Microsoft/aspnet image we can start with so lets build up our dockerfile

FROM microsoft/aspnet
RUN mkdir C:\site

This gets the base image and creates directory that we are going to use for our web files.

RUN powershell -NoProfile -Command \
    Import-module IISAdministration; \
    New-IISSite -Name "Site" -PhysicalPath C:\site -BindingInformation "*:8000:

This creates the web application in IIS and binds it to port 8000 and our path to the web files.

RUN powershell -NoProfile -Command \
    Install-WindowsFeature -Name Web-Mgmt-Service

RUN powershell -NoProfile -Command \
    New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WebManagement\Server -Name EnableRemoteManagement -Value 1 -Force

RUN powershell -NoProfile -Command \
    Get-Service -Name WMSVC

RUN powershell -NoProfile -Command \
    Set-Service WMSVC -startuptype "Automatic"
   
RUN powershell -NoProfile -Command \
    Start-Service -Name WMSVC

RUN powershell -NoProfile -Command \
    net user iisadmin P2ssw0rd /add

RUN powershell -NoProfile -Command \
    net localgroup administrators iisadmin /add

This section is completely optional and all it does is install the web management tools for remote administration. You may want to tweak the container settings such as application pool and start and stop it from the GUI on your Windows 10 machine. If you are not bothered about IIS settings, then you can omit this section.

RUN powershell -NoProfile -Command \
$acl = Get-Acl -Path "C:\inetpub\wwwroot";Set-Acl -Path "C:\site" -AclObject $acl;

This copies the directory permissions set up for the wwwroot directory and assigns it to the site directory, so we don’t end up with nasty permission denied issues.

EXPOSE 8000 8172 4020 4021

We need to expose 8000 for our web application, 8172 for remote IIS admin and 4020 and 4021 are the ports we need opening for remote debugging tools. Visual Studio 2015 remote tools use these ports, other versions use different ports and as yet I cannot find the ports for Visual Studio 2017.

Next we locate our dockerfile using a cmd prompt and run docker build

docker build -t iis-site .

It will take a while to run through and will be quicker in future builds as you will already have the layers that make up the final image.

Now we have our image, lets run with it:-

docker run -d -p 94:94 -v "C:\Users\username\Documents\Visual Studio 2015\Projects\WebApplication4\WebApplication4":c:\site --name web1 iis-site

This creates a container based on our previous iis-site image and creates a mapping to a directory on our Windows 10 machine to the site directory we created in the dockerfile; this container will have the name web1.

Lets test this by finding the ip address:-

docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" web1

This gives me 172.19.184.110 and yours will be different as each container gets its own address. We know we are on port 8000 so open up a browser and browse to your home page:-

image

Great, now lets get debugging. In future releases of Visual Studio 2017 it will be possible to debug straight into a Windows container, but at the moment it is limited to Linux containers, so we need to do a bit more configuration.

We need to install the Remote Tools for Visual Studio 2015 so go here and download it.

Once downloaded, put the .exe in the same directory as your web application on your machine as that is already visible to the container. There are ways to automate the download using Invoke-WebRequest, but I had several issues with resolving the url so it was easier to do it myself.

Create a .bat file with the following and copy that also into the web application directory on your machine:-

rtools_setup_x64.exe /install /quiet

Get the id of the container by using the command:-

docker ps

With the id, lets open an interactive cmd prompt:-

docker exec -it 03a8eb766d5a cmd

Where 03a8eb766d5a is my container identifier.

Run the bat file:-

install-tools.bat

This will take a couple of minutes to run through, but when it is finished you can cd to the C:\Program Files\Microsoft Visual Studio 14.0\Remote Tools directory to take a look.

Exit out of the interactive session and get back to docker and run:-

docker exec -it 03a8eb766d5a "C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe" /nostatus /silent /noauth /anyuser /nosecuritywarn

This will start the remote debugging service msvsmon and your cmd prompt will just sit quiet with no cursor.

So now open up the web application in Visual Studio and go to Debug >> Attach to process

debug-1

Click on the Find button and it should find your container with its id and ip address showing, simply select it.

debug-2

debug-3

Now we need to make sure we choose Managed (v4.6, v4.5, v4.0) code or whatever version of the framework you are using. Also make sure show processes from all users is checked.

Scroll down and choose w3wp and attach. Check the security warning and then start debugging as you would normally do.

debug-4

Ideally it would be best if the remote tools could be downloaded as part of the build and the starting of msvsmon be automatic when F5 in Visual Studio. If you are happy with your container, you could save it as an image using the command:-

docker commit 03a8eb766d5a iis-debug-tools

Just remember to stop it first.

Happy coding.

Up until late last year I was experimenting with Docker container on Windows 10 and Server 2016 using the Experimental version of Docker. Well things took a turn for the worst and basically Docker refused to run and kept crashing. Life being as it is I went onto other things and have only just come back to Docker and installing the release stable version (17.03.0-ce-win1 (10296)) I get this when switching from Linux containers to Windows:-

Docker daemon failed with message:
time="2017-03-02T17:10:44Z" level=warning msg="Running experimental build"
time="2017-03-02T17:10:44.990632000Z" level=debug msg="Listener created for HTTP on npipe (//./pipe/docker_engine_windows)"
time="2017-03-02T17:10:44.995133700Z" level=info msg="Windows default isolation mode: hyperv"
time="2017-03-02T17:10:44.995133700Z" level=debug msg="Using default logging driver json-file"
time="2017-03-02T17:10:44.995632900Z" level=debug msg="WindowsGraphDriver InitFilter at C:\\ProgramData\\Docker\\windowsfilter"
time="2017-03-02T17:10:44.995632900Z" level=debug msg="Using graph driver windowsfilter"
time="2017-03-02T17:10:44.995632900Z" level=debug msg="Max Concurrent Downloads: 3"
time="2017-03-02T17:10:44.995632900Z" level=debug msg="Max Concurrent Uploads: 5"
time="2017-03-02T17:10:45.018215100Z" level=info msg="Graph migration to content-addressability took 0.00 seconds"

….LOTS MORE OF THE MESSAGE HERE…

time="2017-03-02T17:10:45.551683600Z" level=debug msg="start clean shutdown of all containers with a 15 seconds timeout..."
Error starting daemon: Error initializing network controller: Error creating default network: HNS failed with error : The parameter is incorrect.


   at Docker.Backend.ContainerEngine.Windows.DoStart(Settings settings)
   at Docker.Backend.ContainerEngine.Windows.Restart(Settings settings)
   at Docker.Core.Pipe.NamedPipeServer.<>c__DisplayClass8_0.<Register>b__0(Object[] parameters)
   at Docker.Core.Pipe.NamedPipeServer.RunAction(String action, Object[] parameters)

To fix this I stopped the MobyLinux VM that was running via Hyper-V Manager and did a factory reset on the Docker daemon.

image

It did the reset and now runs Windows containers, so if anybody has the same issue try replicating this.

Happy coding

I am working on an app for the Windows Store that requires mapping functionality. As it is a Windows app, it seems logical to use Bing Maps as they also provide an SDK for apps. Currently it is at version 8, but I had a few problems implementing that version so went for version 7 with the hope to upgrade it at some point when I get more traction for the app.

Firstly you need to go to the Bing Maps Developer portal and sign in to request an API key for your project.

Click on the Create Key link and enter some details about the app. For store apps, a key type of Basic should suffice as we are not doing any enterprise level development. Choose Universal Windows app for the type and any URL you have for your in dev app (I use a placeholder page on my website where the app privacy policy etc. are going to go).

Some transactions with the Bing Maps API are billable, but you have to exceed a limit of 50,000 transactions in any 24 hour period, a listing of billable transactions can be found here. The reason I am mentioning this is in case you are offering a free app and a large number of users start to hit the service you could be liable to paying out.

image

While there have a look at the feature set for V7 with the online examples. As these are all HTML and JavaScript based samples, they are also ideal for a WinJS UWP app.

To get the SDK for V7, you need to go to the Visual Studio Marketplace and download the Bing Maps SDK for Windows 8.1 Store apps.

This will give you a VSIX to install into Visual Studio.

Open up Visual Studio and choose New Project >> JavaScript >> Windows >> Universal >> WinJS App

image

This will give you a basic template with enough functionality to test out the mapping API.

Choose the Target versions to support (Build 10586 should suffice)

image

Add a reference to the Bing Maps for JavaScript extension.

image

It will highlight a compatibility warning linking to http://go.microsoft.com/fwlink/?LinkID=309181 as it is really should be used with Windows 8.1 apps.

So now when we expand the References in our app we can see the required files for the mapping functionality we are going to build with.

I like to structure my apps, so that the main entry view (index.html and main.js) do a check on load and change the view depending on screen size/device etc. So I create a home view which has the ready, unload and updateLayout functionality. This home view is then loaded from the main entry view and inserted into a content host element.

 

We now need to add the script references and an element for the map in the home.html file:-

The CSP is important because it defines which urls are safe to load from. The div with the id webview is where our map will go.

Then in the home.js file add this

There you go, our simple map in the app.

image

There is so much more functionality that can ne added to this app such as getting the geolocation of the user and adding pushpins to different locations, but I will leave that for another post.

Happy coding.

If you want to monetize your UWP apps, it might be part of you plan to have some kind of trial so that uses can try out the basic functionality of your hard work. This can be achieved in two places, firstly you need to test and set the properties in the app. Then you need to change the properties of your app submission in the Windows Dev Center. So here I will cover how we write the code to test for a trial installation of your app.

In my MoonPhase app, I have limited some functionality in the trial version. Basically a user can view the current details on the Moon, but if they want to move forward or backwards in time to see what the Moon looks like on different days, then a message popups up to tell them they cannot do that in the trial. This way they get to use the basic functionality and if they find the app useful, then they can pay for the full version in the app store.

Trial Functionality in UWP

So here is the logic I have in the JavaScript for the view

The ‘message’ element is a div in the HTML that the fly out will append to when the ‘previous’ button is clicked.

In the JavaScript listing above there is a call to getLicenseInfo(), this function takes in a Boolean that if set to true then it is in trial mode and needs to use the CurrentAppSimulator as opposed to the CurrentApp. The CurrentAppSimulator does just that, it simulates certain properties of the application that you have control over.

So to test locally simply pass in true.

var licenseInformation = getLicenseInfo(true);

The CurrentAppSimulator will then look for the WindowsStoreProxy.xml file that resides on your drive, usually somewhere like this:-

%UserProfile%\AppData\Local\Packages\<app package folder>\LocalState\Microsoft\Windows Store\ApiData\WindowsStoreProxy.xml

Depending on what you are testing for, you can populate the sections you need. I am testing for a trail version, so set the IsTrial within the App element to true. You can now run the app in the debugger and you can step through your code to see what paths it is taking. In my case I show the message fly out notifying the user of the trial status.

One thing to remember though is to take out the Boolean or set to false before submitting to the store. I am still looking for a better way to handle this and was hoping there would be some sort of pre-processor functionality like what is used in C# that could be switched when in debug mode.

Submitting Through the Windows Dev Center

So once you are happy to publish the app and the Boolean has been taken out or set correctly, go to the ‘Pricing and availability’ section of your submission.

image

The use the drop down to set the trial period.

image

When a user first installs the app in trial mode the real IsTrial property will be set to true and each time the app launches it will check the install date and if this is still set to true then the app won’t launch and the user will be presented with a Windows dialog to prompt them to purchase from the store. When they do purchase, then the IsTrial is set to false and they get all the functionality.

Happy coding

I am posting this here as somebody else thinking of creating store apps for Windows 10 might thing it interesting. I intend on following this post up with another about app promotion techniques.

App Statistics

Once you have an app published in the Windows Store, you can get to a wealth of information about which markets, demographics and devices are the most popular. This is in the form of in browser views, but you can also download the raw statistics for analysis using Excel for example as I have done here.

I have 5 apps in the store currently, but I am only going to concentrate on 3. MoonPhase is the oldest and has been in the store since Windows 8 was first released. It has over 6000 downloads to date and has recently been migrated to a Windows 10 UWP app. It was originally free, but I started changing for it a couple of months ago. I don’t make a huge amount of money from this app, but its better than nothing.

image

Looking at the past 30 days acquisitions and usage, the United States comes at the top of both with UK second.

Next is WebUp, this is another paid app which is just under two months old. It is aimed at the enterprise market sector that is responsible for web site monitoring, whether that be corporate intranets or public facing web sites.

image

These stats are a bit strange as they show United States download more, but the UK use the app more. Is there something stopping the US from using the app more after they have paid for it?

Both MoonPhase and WebUp show that the United States are quite happy to spend money in the store even if they don’t get the full use out of the software. The UK looks like they are better at getting more bang from their buck (or pound). WebUp is more expensive than MoonPhase which might be the reason the UK is lower in acquisition rates. I am about to run an experiment where both apps will be priced much lower and I will see if the price is forming a barrier to UK acquisition rates.

Thirdly is GetWalking. This is a free app aimed at the personal health sector, it is a simple pedometer that measures both distance walked and steps taken. It is the youngest of the 3 apps as it has only been in the store less than a month. I do intend on monetizing this app, possibly through advertisements, but not entirely sure yet. There are more features I wish to add, but currently I am just getting some stats in an MVP kind of way.

image

The chart shows that the UK has both the highest acquisition and usage, again with the US second in acquisitions, but strangely China overtakes it with usage. It seems that the Chinese market get more use out of this app than the US.

Interestingly all three app show that both the US and UK are either at the top or near the top of the charts in acquisition and usage. I am a UK based developer and these apps are published in all the markets that Microsoft allow, so I was expecting there to be more numbers from markets such as India and China. Is it a language thing perhaps?

Also very strange that an app can be used in the United Arab Emirates, but never acquired from there. Does this show that app statistics are not entirely tied to a users country of origin (Windows account country registration)?

None of these app have undergone any app promotional exercises except I have blogged about MoonPhase and WebUp. The Windows Store statistics show that all 3 of these apps get views from users coming to the store and searching not from outside search engines or sites such as Google/Bing or any of my previous posts (except for a handful, not worth bothering with).

My next task is to try and promote these apps more outside the store.