Tag: visual studio

Posted on

Create a certificate for package signing AND deploy a MSIX package

I wanted my application to be available via a MSIX installer. This new MSIX installer supports all type of Windows applications including Win32, WPF, WinForm and UWP.

I struggled a few days to get the certificate right so that is why I published this article. This article goes through the process of creating a certificate and adding this to the app installer package.

First you need to add a new project to your solution. The solution type is called Windows Application Packaging Project. This is done by right clicking the solution and go to Add > New Project…

Determine the subject of your packaged app
To use a certificate to sign your app package, the “Subject” in the certificate must match the “Publisher” section in your app’s manifest.

For example, the “Identity” section in your app’s AppxManifest.xml file should look something like this:

<Identity
    Name="12345678-1234-1234-1234-1234567890ab"
    Publisher="CN=Contoso Software, O=Contoso Corporation, C=US"
    Version="1.0.2.0" />

The “Publisher”, in this case, is “CN=Contoso Software, O=Contoso Corporation, C=US” which needs to be used for creating your certificate.

Then run the following commands in an elevated PowerShell prompt:

  1. PS C:\WINDOWS\system32> New-SelfSignedCertificate -Type Custom -Subject “CN=Contoso Software, O=Contoso Corporation, C=US” -KeyUsage DigitalSignature -FriendlyName “Certificate for Installing MSIX/Appx from Contoso Software” -CertStoreLocation “Cert:\CurrentUser\My” -TextExtension @(“2.5.29.37={text}1.3.6.1.5.5.7.3.3”, “2.5.29.19={text}”)

    PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

    Thumbprint Subject
    ———- ——-
    2B046FBC587DD867989D6165570B4C144F557FCE CN=Contoso Software, O=Contoso Corporation, C=US
  2. PS C:\WINDOWS\system32>Set-Location Cert:\CurrentUser\My
  3. PS Cert:\CurrentUser\My> $password = ConvertTo-SecureString -String mypassword -Force -AsPlainText
  4. PS Cert:\CurrentUser\My> Export-PfxCertificate -cert “2B046FBC587DD867989D6165570B4C144F557FCE” -FilePath c:\Contoso.Software.pfx -Password $password

    Directory: C:\

    Mode LastWriteTime Length Name
    —- ————- —— —-
    -a—- 7-9-2020 08:42 2756 Contoso.Software.pfx

Then add the certificate to the package installer in Visual Studio:

Next publish the app:

Import the certificate if it is not already installed

Start Manage computer certificates to import the certificate to the computer(s) to which you wish the app to deploy

If it is not present in Thrusted People, import the certificate

Next publish the app

And double click the PackagingProject.appinstaller from the installer folder

Posted on

Report progress in a task in C sharp

One of my first questions starting programming in Visual Studio WPF was how to run processes without freezing the GUI.

After learning the basic concepts of backgroundworkers and tasks in c sharp programming I wanted to know how to report task progress while the task was not yet finished.

I found all kind of solutions to update a progress bar. I also found solutions to use the result for a specific task.

Think still missing for me was to get a screen to show task progress, with detailed logging while the task was still running. In the end this article helped me finding a solution: https://social.technet.microsoft.com/wiki/contents/articles/19020.progress-of-a-task-in-c.aspx

To implement this logic in a solution I started with a form on which I added a button and a listbox.

The button got the following implementation:

private async void ButtonAsyncFileProcessing_Click(object sender, RoutedEventArgs e)
{
    var progressIndicator = new Progress<MyTaskProgress>(ReportProgress);
    await MyMethodAsync(progressIndicator);
}

For the progress indicator I added the following class:

public class MyTaskProgress
{
    //current progress
    public int CurrentProgressAmount { get; set; }
    //total progress
    public int TotalProgressAmount { get; set; }
    //some message to pass to the UI of current progress
    public List<string> CurrentProgressLogging { get; set; }
}

The async method I used for testing was this:

async Task MyMethodAsync(IProgress<MyTaskProgress> progress)
{
    int sleepTime = 1000;
    int totalAmount = 10000;
    List<string> log = new List<string>();

    for (int i = 0; i <= totalAmount;)
    {
        await Task.Delay(sleepTime);
        log.Add(string.Format("On {0} Message", i));
        progress.Report(new MyTaskProgress
            {
                CurrentProgressAmount = i, TotalProgressAmount = totalAmount, CurrentProgressLogging = log });
        i = i + sleepTime;
    }
}

The ReportProgress method used in the button click progressIndicator:

private void ReportProgress(MyTaskProgress progress)
{
    UpdateScreen(progress.CurrentProgressLogging,
        string.Format("{0} out of {1}",
        progress.CurrentProgressAmount,
        progress.TotalProgressAmount));
}

And this last method calls a UpdateScreen method:

private void UpdateScreen(List<string> info, string status)
{
    lbOutput.Items.Clear();
    foreach (string s in info)
    {
        lbOutput.Items.Add(s);
    }
    buttonAsyncFileProcessing.Content = "AsyncFileProcessing" +
    "\n" + status;
}

The article that helped me understanding Tasks and backgroundworkers is: https://blog.stephencleary.com/2013/05/taskrun-vs-backgroundworker-intro.html

Posted on

Change settings for eventlog in Service installer

I was developing a Windows service. Everything went smooth until I was asked to add logging for the service into a separate log file in the event viewer. I want to share my journey with you so it may help finding a solution for similar or the same issue.

After I had learned to install a service using a service installer, I ran into some troubles configuring the event viewer. My service had three logging options. First is to a text file on disk, second is to the Windows Event Viewer and I added an extra option to send a message to a messaging app. All service issues where logging fine. As a last option I was asked to log to a separate log in the event viewer like this:

First I tried adding all kind of options to my logging library to check, add and change the logging destination. That didn’t work and I found that the log needed to be set during initial installation of the service. Reason that previous attempts failed was that when changing these settings, the application needs admin privileges and changing logging options afterwards needed the machine to be rebooted etc.

I searched the internet for a solution and after a couple o hours I stumbled upon this article: https://stackoverflow.com/questions/115488/what-is-the-most-reliable-way-to-create-a-custom-event-log-and-event-source-duri

The post of Simon Mattes in this article helped me out. I altered the code a bit for my own use:

public ProjectInstaller()
{
    InitializeComponent();
    //Skip through all ServiceInstallers.
    foreach (ServiceInstaller ThisInstaller in Installers.OfType())
    {
        //Find the first default EventLogInstaller.
        EventLogInstaller ThisLogInstaller = ThisInstaller.Installers.OfType().FirstOrDefault();
        if (ThisLogInstaller != null)
        {
            //Modify the used log from "Application" to the same name as the source name.
            //This creates a source in the "Applications and Services log" which separates your service logs from the default application log.
           ThisLogInstaller.Log = "TestApplication"; //ThisLogInstaller.Log = ThisLogInstaller.Source;
           ThisLogInstaller.Source = "TestSource";
        }
    }
}

Check out this post on adding an installer to your application: http://kannekens.nl/registering-installing-a-windows-service-part-2/


Posted on

Registering / installing a Windows service part 2

In this article I want to describe an easy way to add an easy installer to a Windows Service project.

Steps are: – Add the installer for the service
– Configure the service parameters
– Add parameters to start up of the program


Add the installer for the service can be done when you open the service.cs. This will show a gray screen with two links:

Right click this screen and select Add installer in the pop up menu. This will add a ProjectInstaller.cs file with a ProjectInstaller class inside.

Open the Projectinstaller file. This will show two components.

Change settings for the two components according to your needs.

Last step is to add the installer to the program start up. For this we need to change the Program.cs.

static class Program
{
    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    static void Main(string[] args)
    {
        if (args.Length > 0)
        {
            //Install service
            if (args[0].Trim().ToLower() == "/i")
            {
                System.Configuration.Install.ManagedInstallerClass.InstallHelper(
        new string[] { "/i", Assembly.GetExecutingAssembly().Location });
            }

            //Uninstall service                 
            else if (args[0].Trim().ToLower() == "/u")
            {
                System.Configuration.Install.ManagedInstallerClass.InstallHelper(
        new string[] { "/u", Assembly.GetExecutingAssembly().Location });
            }
        }
        else
        {
            ServiceBase[] ServicesToRun;
            ServicesToRun = new ServiceBase[]
            {
            new ServiceMonitor()
            };
            ServiceBase.Run(ServicesToRun);
        }
    }
}

Posted on

Simple unit tests in Visual Studio solutions

In Visual Studio it is really simple to add unit tests that are automatically run in your build script. Right click your solution to add a test project:

Add a few test methods:

Check this Step-By-Step for an explanation:

https://visualstudiomagazine.com/articles/2013/07/29/test-driven-development-with-visual-studio-2012.aspx

Check this link for some Unit test basics:

https://docs.microsoft.com/en-us/visualstudio/test/unit-test-basics?view=vs-2017

/// <summary>
/// Test if flipcoins throws as many times as requested
/// </summary>
[TestMethod()] public void FlipCoinsTest1Times()
 {
     //Arrange
     int odd, even;
     int times = 1;

     //Act
     CoinFlipper coinFlipper = new CoinFlipper();
     coinFlipper.FlipCoins(times, out odd, out even);
 
    //Assert     Assert.IsTrue(times == odd + even);
 }

Open Test explorer window

Right click a selection of tests and select “Run selected tests”.

When the tests are OK, we can check in the solution. Default the Build in Azure will run libraries with names containing *test*.

The results for this solution: 8 tests passed.

Posted on

Unblock project files in Visual Studio

When you open a copy of project files from a remote location / downloaded from the internet you get the message that the project location is not trusted:

or a security warning when opening the project warning that the project file may have come from a location that is not fully trusted:

First assure yourself that the files you downloaded are from a trustworthy source. If this is the case then you could remove the warnings from these files like this:

Unblock downloaded files in folder including subfolders:

gci -path “C:\BeeHive” -recurse | Unblock-File (replace “C:\BeeHive” with the folder in which you want to unblock all files)

Posted on

Continuously Deploy Your ClickOnce Application From Your Build Server

http://blog.danskingdom.com/continuously-deploy-your-clickonce-application-from-your-build-server/ from Daniel Schroeder’s (aka deadlydog) Programming Blog

ClickOnce applications are a great and easy way to distribute your applications to many users, and have the advantage of offering automatic application updates out-of-the-box. Even though ClickOnce applications are super easy to deploy from Visual Studio (literally 3 clicks, just click Build –> Publish –> Finish), you may still want to have your build system publish the updates for various reasons, such as:

You don’t want you (or your team members) to have to remember to manually publish a new version all the time; even if it is very quick and easy.

If you are signing your ClickOnce application (to make your app more secure and avoid annoying Windows security warnings during every update), your team members may not have the certificate installed, or you may not want them to know the certificate password.

All of the other benefits of deploying automatically from a build server; you can be sure the project was built in Release mode, all unit tests have run and passed, you are only publishing a new version of the application from a specific branch (e.g. master), etc.

In this post I’m going to show how to continuously deploy your ClickOnce application using Visual Studio Team Services (VSTS), but you can adopt what’s shown here to work on any build system, such as Team City or Jenkins.

Step 1 – Configure and publish your ClickOnce application manually

Before we can publish a new version of the application from the build server, we first have to build the project to create the artifacts to publish. And even before that, we have to make sure the project is setup properly with all of the required ClickOnce metadata. You will typically do this by going into your project Properties page and going to the Publish tab. There are several other websites and blog posts that discuss configuring a project for ClickOnce deployment, including the official MSDN documentation for configuring and publishing ClickOnce applications, so I won’t go into it any further here.

Basically you should have your project in a state where you can easily publish a new version manually, and it is configured the way that you want (includes the necessary files, has the destination to publish to specified, specifies if the application is only available online or not, etc.). Once you’ve published your project manually and confirmed that it’s configured the way you like, we can move onto the next step.

Step 2 – Setup the build on your build server

On your build server you will want to configure a new vanilla build that builds your project/solution. There are a couple modifications you will need to make that are different from building a regular console app or class library project.

The first difference is that you will need to provide the “/target:Publish” argument to MSBuild when it builds your project. Here is what this looks like in VSTS:

This will cause MSBuild to build the required artifacts into an “app.publish” directory. e.g. bin\Debug\app.publish.

The next difference is that you will want to copy that “app.publish” directory to your build artifacts directory. To do this, you will need to add a Copy Files step into your build process that copies the “app.publish” directory from the ClickOnce project’s bin directory to where the build artifacts are expected to be. You will want to do this before the step that publishes your build artifacts. Here is what this looks like in VSTS:

So we copy the files into the build artifacts directory, and then the Publish Build Artifacts step at the end will copy those files to wherever you’ve specified; in my case it’s a network share.

If you like you can now run the build and see if it succeeds. If the build fails with an error relating to an expired certificate or pfx file, see my other blog post on importing the required certificate on the build server at build-time, which involves adding one more “Import-PfxCertificate.ps1” build step before the MSBuild step.

For completeness sake, this is what my Publish Build Artifacts step looks like in VSTS, and you’ll also notice the “Import-PfxCertificate.ps1” step before the MSBuild step as well:

So we now have the ClickOnce artifacts being generated and stored in the appropriate directory. If you wanted, you could publish the build artifacts to the ClickOnce application’s final destination right now (instead of a file share as I’ve done here), but I’m going to follow best practices and separate the application “build” and “deployment” portions into their respective subsystems, as you may want separate control over when a build gets published, or maybe you don’t want to publish EVERY build; only some of them.

Hopefully at this point you are able to create a successful build, but we’re not done yet.

 Step 3 – Publish the build artifacts to the ClickOnce application’s destination

Now that we have the build artifacts safely stored, we can publish them to the ClickOnce application’s destination. With VSTS this is done by using the Release subsystem. So create a new Release Definition and setup an Environment for it. By default it adds a “Copy and Publish Build Artifacts” step to the release definition. When configuring and using this default step, I received the error:

[error]Copy and Publish Build Artifacts task is not supported within Release

So instead I removed that default step and added a simple “Copy Files” step, and then configured it to grab the files from the file share that the build published the artifacts to, and set the destination to where the ClickOnce application was publishing to when I would do a manual publish from within Visual Studio. Here is what that step looks like in VSTS:

You should be able to run this release definition and see that it is able to post a new version of your ClickOnce application. Hooray! I setup my releases to automatically publish on every build, but you can configure yours however you like.

If you make changes and commit them, the build should create new artifacts, and the release should be able to publish the new version. However, if you launch your ClickOnce application, you may be surprised that it doesn’t actually update to the latest version that you just committed and published. This is because we need one additional build step to actually update the ClickOnce version so it can detect that a new version was published. If you launch another build and publish them, you’ll see that the files being published are overwriting the previous files, instead of getting published to a new directory as they are supposed to be.

You may be wondering why we need another build step to update the ClickOnce version. Part of the build artifacts that are created are a .application manifest file, and a directory that contains the applications files, both of which have the ClickOnce version in them. Can’t we just modify the directory name and .application manifest file to increment the old version number? This was my initial thought, but the .application manifest file contains a cryptography hash to ensure that nobody has tampered with it, meaning that it needs to contain the proper version number at the time that it is generated.

Step 4 – One more build step to update the ClickOnce version

The ClickOnce version is defined in your project file (.csproj/.vbproj) (as the <ApplicationVersion> and <ApplicationRevision> xml elements), and is different from the assembly version that you would typically set to version your .dll/.exe files via the AssemblyInfo.cs file. Unless you manually updated the ClickOnce version in Visual Studio, it will still have its original version. When publishing the ClickOnce version in Visual Studio, Visual Studio automatically takes care of incrementing ClickOnce version’s Revision part. However, because we’re publishing from our build system now, we’ll need to come up with an alternative method. To help solve this problem, I have created the Set-ProjectFilesClickOnceVersion GitHub repository. This repository houses a single Set-ProjectFilesClickOnceVersion.ps1 PowerShell script that we will want to download and add into our build process.

In order for the build system to access this Set-ProjectFilesClickOnceVersion.ps1 script you will need to check it into source control. Also, you need to make sure you add this build step before the MSBuild step. Here is what this step looks like in VSTS:

The Script Filename points to the location of the Set-ProjectFilesClickOnceVersion.ps1 script in my repository. Also note that I set the Working Folder to the directory that contains the .csproj project file. This is necessary since we are dealing with relative paths, not absolute ones.

For the Arguments I provide the name of the project file that corresponds to my ClickOnce application, as well as the VSTS Build ID. The Build ID is a globally unique ID that gets auto-incremented with every build, and most (all?) build systems have this. The script will translate this Build ID into the Build and Revision version number parts to use for the ClickOnce version, to ensure that they are always increasing in value. So you should never need to manually modify the ClickOnce version, and every build should generate a version number greater than the last, allowing the ClickOnce application to properly detect when a newer version has been published.

Maybe you update your application’s version number on every build, and want your ClickOnce version to match that version. If this is the case, then use the –Version parameter instead of –BuildSystemsBuildId. The other alternative is to use the –IncrementProjectFilesRevision switch to simply increment the ClickOnce Revision that is already stored in the project file. If you use this switch, you need to be sure to check the project file back into source control so that the Revision is properly incremented again on subsequent builds. I like to avoid my build system checking files into source control wherever possible, so I have opted for the BuildSystemsBuildId parameter here.

The last argument I have included is the UpdateMinimumRequiredVersionToCurrentVersion parameter, and it is optional. If provided, this parameter will change the ClickOnce application’s Minimum Required Version to be the same as the new version, forcing the application to always update to the latest version when it detects that an update is available. I typically use this setting for all of my ClickOnce applications. If you still plan on publishing your ClickOnce applications from Visual Studio, but want this functionality, simply install the AutoUpdateProjectsMinimumRequiredClickOnceVersion NuGet Package.

That’s it! Now if you launch another build it should create new artifacts with a larger ClickOnce version number, and once published your application should update to the new version.

 

Bonus – Displaying the ClickOnce version in your application

The ClickOnce application version number may be different than your assembly version number, or perhaps you don’t update your product’s version number on every publish; it’s easy to forget. I typically like to use semantic versioning for my projects, which only involves the first 3 version parts. This leaves the last version part, the Revision number, available for me to set as I please. I will typically use the ClickOnce Revision in my application’s displayed version number. This makes it easy to tell which actual release a client has installed in the event that the product version was not updated between releases. The code to do it is fairly simple.

public Version ApplicationVersion = new Version(“1.11.2”);
private void MainWindow_Loaded(object sender, RoutedEventArgs e)
{
// If this is a ClickOnce deployment, append the ClickOnce Revision to the version number (as it gets updated with each publish).
if (ApplicationDeployment.IsNetworkDeployed)
ApplicationVersion = new Version(ApplicationVersion.Major, ApplicationVersion.Minor, ApplicationVersion.Build,
ApplicationDeployment.CurrentDeployment.CurrentVersion.Revision);
// Display the Version as part of the window title.
wndMainWindow.Title += ApplicationVersion;
}

Here I hard-code the product version that I want displayed in my application in a variable called ApplicationVersion. When the WPF application is launched, I obtain the ClickOnce Revision and append it onto the end of the version number. I then display the version in my application’s window title, but you might want to show it somewhere else, such as in an About window. If you want, you could even display both the full application version and full ClickOnce version.