My first Dynamics 365 Extension – step by step – third step

I got a response from Microsoft from my first step.

Thank you for submitting your app for consideration to be listed on AppSource.

Once we have had the opportunity to review your app, you will receive a follow up within 1-2 weeks or earlier with a status regarding your submission and next steps as relevant.

Where you are in the process:

appsourceprocess

Request ID#: 835

Thank you,

The Microsoft AppSource team

This message from Microsoft is an important part of a program, service, or product that you or your company purchased or participate in.

From hereon I get out of sync with the steps on PartnerSource:

Step 3: Build your app

Find more information on how to build an extension in our learning plan on the Dynamics Learning Portal (DLP) (coming soon).

Refer to the Technical Validation Guidelines for Dynamics 365 for Financials (coming soon) to get insight into app technical requirements and recommendations.

To build the app I need to go through many steps.  You are building experience, not a solution.  Therefore we must make sure to have;

  • ToolTip for every field and every action
  • Correct value for ApplicationArea
  • Permission Set(s)
  • Friendly notifications
  • Assisted Setup
  • Help web page(s)
  • Help video(s)

I will go through this list in later blog posts.

Now for the main topic in this post.  Dynamics 365 requires all extension packages to be signed with a code signing certificate.  Microsoft says:

To sign an extension package

To help validate the authenticity of an extension package (the .navx file), we recommend that you have it signed. Code signing is a common practice for many applications. For more information about code signing, see Authenticode and Introduction to Code Signing in the MSDN Library.

  1. To sign an extension package, you need a computer that has the following:
    1. A code signing tool, such as SignTool or CodeSign.SignTool is part of the Windows Software Development Toolkit. For more information, see SignTool.
    2. Microsoft Dynamics NAV 2016 or later.
  2. Obtain a certificate that is enabled for the code signing purpose. You can have certificate as a file or installed in the certificate store of the computer.
  3. It is optional but we recommend that you use a time stamp when signing the .navx file.
  4. Sign the .navx file by using your signing tool.

So, if you want to publish to Microsoft AppSource get your self a valid code signing certificate.  There are number of vendors that can sell a code signing certificate.  Bing delivers this list.

I was allowed to quote one of Microsoft employees:

“I would only suggest using a self-signed certificate for testing and development purposes. If you plan to submit the extension as an app for Dynamics 365 for Financials, you will need to use a certificate from a trusted third party certification authority.

Every version of the extension doesn’t need to be signed using the same certificate. A new version could be signed with a different/new certificate.”

If you don’t already have the SignTool installed you can download it here for windows 7 and 8 and here for windows 10.  On Windows 10 all you need to select in the install process is the Windows Software Developement Kit.

sigtoolinsert

When the installation finishes you will find the SignTool.exe in the folders:

  • x86 -> C:\Program Files (x86)\Windows Kits\10\bin\x86
  • x64 -> C\Program Files (x86)\Windows Kits\10\bin\x64\

When I create the application package (navx file) I check for my code signing certificate and if not found I create one.  Now, of course this is done in PowerShell.

$BaseFolder = (Get-Item $psISE.CurrentFile.FullPath).Directory
. (Join-Path $BaseFolder 'AppPackageSettings.ps1')

Get-NAVAppManifest `
-Path $AppManifestFileName `
| New-NAVAppPackage -Verbose `
-Path $AppPackageFileName `
-SourcePath $ResourceFolder `
-Force

if (!(Test-Path -Path $CodeSigningCertificate))
{
$SecurePassword = ConvertTo-SecureString -String $CodeSigningCertificatePassword -AsPlainText -Force
New-SelfSignedCertificate –Type CodeSigningCert –Subject "CN=ExtensionTest" -CertStoreLocation Cert:\LocalMachine\My
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -eq "CN=ExtensionTest"} | Export-PfxCertificate -FilePath $CodeSigningCertificate -Password $SecurePassword -Force
Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\Root -Password $SecurePassword -FilePath $CodeSigningCertificate
}

& $SigToolExecutable sign /t http://timestamp.verisign.com/scripts/timestamp.dll /f $CodeSigningCertificate /p $CodeSigningCertificatePassword $AppPackageFileName

The first two lines are used to import modules and parameters from the AppPackageSettings file (below).  Lines four to nine create the application package (navx file), Lines eleven to seventeen check if the certificate selected in my AppPackageSettings is present, and if not it will be created in the certificate store and exported to a file.  For this to work this script has be executed in elevated mode (Run as Administrator).

Last line uses the SignTool to sign the application package (navx file).

My AppPackageSettings file looks like this

Set-ExecutionPolicy Unrestricted

Import-Module 'C:\Program Files\Microsoft Dynamics NAV\100\Service\NavAdminTool.ps1' | Out-Null

$NavIde = 'C:\Program Files (x86)\Microsoft Dynamics NAV\100\RoleTailored Client\finsql.exe'
$NavModelTools = 'C:\Program Files (x86)\Microsoft Dynamics NAV\100\RoleTailored Client\NavModelTools.ps1'
. $NavModelTools $NavIde | Out-Null

$ServerInstance = 'DynamicsNAV100'
$Tenants = @('Default')

#[System.Guid]::NewGuid().toString()

$AppId = '263f2b5c-4580-41cd-9eea-d1093519adc4'
$AppManifestName = 'GLSourceNames'
$AppManifestPublisher = 'Kappi ehf.'
$AppManifestVersion = '1.0.0.0'
$AppManifestDescription = 'G/L Source Names'
$PermissionSets = ('GL SOURCE NAMES')

$AppManifestFileName = (Join-Path $BaseFolder 'AppManifest.xml')
$AppPackageFileName = (Join-Path $BaseFolder 'AppPackage.navx')
$ResourceFolder = (Join-Path $BaseFolder 'Resources')
$SourceName = (Join-Path $BaseFolder 'Original.txt');
$ModifiedName = (Join-Path $BaseFolder 'Modified.txt');
$PermissionSetFilePath = (Join-Path $ResourceFolder 'AppPermissionSet-%1.xml')

$SigToolExecutable = 'C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe'
$CodeSigningCertificate = (Join-Path $BaseFolder 'MyCodeSigningCertificate.pfx')
$CodeSigningCertificatePassword = 'codesignaturepassword'

Don’t worry, I will share the whole script package when the time is right.

When I have the correct code signing certificate I update the two last lines in the settings file and point to my brand new certificate.

In next step we will start coding in C/AL – stay tuned.

 

My first Dynamics 365 Extension – step by step – second step

Now I need to be recognized as a developer.

Step 2: Complete Microsoft Development Center registration

Before you can publish your app to AppSource, you will need a Microsoft Development Center account.  A developer account lets you submit apps to Microsoft marketplaces, including the Windows Store, Office Store, Azure Marketplace, and Microsoft AppSource.

You can check to see if you already have access or register here:
https://developer.microsoft.com/en-us/store/register

NOTE:  You only need one developer account per company (not one per submission); a one-time registration fee applies.

This was a rather easy step, just needed to use my credit card.

I will go ahead and try the next step.  See you soon…

My first Dynamics 365 Extension – step by step – first step

You could say: “It is about time…”

And you would be right.  Finally, I am back to my blog.

My goal is to deliver my first app to Microsoft AppSource.  You can find a step by step instructions on PartnerSource.

I want to start with a very simple extension.  If you look closely at a general ledger entry in NAV and Dynamics 365 you will see that there are fields with information about the entry source.  For example, if you post a sales invoice then the customer will be the source.  If you post a purchase invoice then the vendor will be the source.  If you look at the balance account for a bank account you will see the actual bank account number as source.

My goal here is simple.  I want to add this information to the general ledger entry page.  Additionally I want to show the name for each customer, vendor or bank account.  After installation of this extension the user will be able to browse through his general ledger entries and see the source information for each entry.  Here is an example for CRONUS G/L Account No. 5610.

modifiedglentries

You can also see on the above screen shot that I have added a button to open the source card directly from the G/L Entry.

Today I will do the first step.

Step 1: Submit your app idea for pre-approval

We will review your app idea, provide any relevant feedback, and pre-approve.  Submit your idea here: Microsoft AppSource.

After pre-approval, you will receive a unique object range for your app along with additional information to guide you through the development, validation, and publishing of your app.

I will do my next blog post about step 2 and so forth…