Publishing an Extension with Microsoft Dynamics Business Central On-Prem
I have been developing extensions for Microsoft Dynamics Business Central for a while but I had never attempted to publish one in the wild until now. Of course, I didn't start with something easy - can't have that now, can we? No, I did one with an upgrade process to pull existing data from a legacy C/AL customization into an extension. It was pretty straightforward until I went to put it onto the production server and I was greeted with this:
If you're deploying to AppSource, you will want to sign your extension but for an on-premise installation, it's not necessary. Adding the -SkipVerification option gets you past that.
Now the fun really began. NAV wanted to compile and it was generating all sorts of scary messages:
There are several articles about this already, some with different suggestions. I found one that suggested publishing the System and Application packages using the -PackageType SymbolsOnly option. I took the files from my .alpackages folder but can get them from the server. You will need to substitute the server, port and version for the values you are using, but this should allow you do download your packages, assuming you have your development service endpoint turned on. Also, note the "Enable loading application symbol references at server..." setting. That's going to play into this as well.
Note, you may not have a System.app file loaded on the server by default. There is one available in the installation files under ModernDev\program files\Microsoft Dynamics NAV\130\AL Development Environment. Install it using the -PackageType SymbolsOnly option.
This did appear to eliminate most of the above detritus and left me tantalizingly close to success.
What??? My Customer table isn't missing! I'm looking right at it.
Another suggestion I found was to generate symbols. In order to do that, you need to have a development setting on the service configured correctly. I set the "Enable loading application symbol references at server startup" setting and restarted the service. I then generated symbols with the finsql executable located in the NAV RoleTailored Client folder. This needs to be run from an elevated command prompt. The finsql.exe in the service folder will not work for this. I emphasize this after spending a half-hour trying to figure out why it wasn't working)
finsql.exe Command=generatesymbolreference, ServerName=MSSQLSERVER2016, Database=Silverware
This will return right away. You need to check it by looking for .txt files.
dir *.txt
When the process has completed successfully, it will create a navcommandresult.txt file. Otherwise it will create a file named naverrorlog.txt, which will have any errors.
type naverrorlog.txt
If you see an error that the file does not exist, it means the process isn't done. On my server it took about 15 minutes. After this was done, I tried again and it still didn't work. I went back to my object and recompiled it and I discovered that when I fixed the field name, I introduced some other field naming problem (I can't remember what) that caused my schema to not sync. I quickly fixed that but the error persisted.
This was a pretty easy one to get past. I was developing on 2.1 but I was able to set the runtime value in my app.json to 2.0 and still compile. Since this is a minimum value, it's probably best to leave it at that unless you know otherwise.
Also, a note about the license incompatibility message - that's apparently a known bug. You can ignore it.
On to the next error...
If you're deploying to AppSource, you will want to sign your extension but for an on-premise installation, it's not necessary. Adding the -SkipVerification option gets you past that.
Now the fun really began. NAV wanted to compile and it was generating all sorts of scary messages:
There are several articles about this already, some with different suggestions. I found one that suggested publishing the System and Application packages using the -PackageType SymbolsOnly option. I took the files from my .alpackages folder but can get them from the server. You will need to substitute the server, port and version for the values you are using, but this should allow you do download your packages, assuming you have your development service endpoint turned on. Also, note the "Enable loading application symbol references at server..." setting. That's going to play into this as well.
http://localhost:7049/DynamicsNAV130/dev/packages?publisher=Microsoft&appName=Application&versionText=13.0.0.0
http://localhost:7049/DynamicsNAV130/dev/packages?publisher=Microsoft&appName=System&versionText=13.0.0.0
Note, you may not have a System.app file loaded on the server by default. There is one available in the installation files under ModernDev\program files\Microsoft Dynamics NAV\130\AL Development Environment. Install it using the -PackageType SymbolsOnly option.
This did appear to eliminate most of the above detritus and left me tantalizingly close to success.
I had just forgotten to rename my source field and it was interfering with the name in my extension. I renamed it and I thought all would be fine but I was wrong. I was very wrong.
What??? My Customer table isn't missing! I'm looking right at it.
Another suggestion I found was to generate symbols. In order to do that, you need to have a development setting on the service configured correctly. I set the "Enable loading application symbol references at server startup" setting and restarted the service. I then generated symbols with the finsql executable located in the NAV RoleTailored Client folder. This needs to be run from an elevated command prompt. The finsql.exe in the service folder will not work for this. I emphasize this after spending a half-hour trying to figure out why it wasn't working)
finsql.exe Command=generatesymbolreference, ServerName=MSSQLSERVER2016, Database=Silverware
This will return right away. You need to check it by looking for .txt files.
dir *.txt
When the process has completed successfully, it will create a navcommandresult.txt file. Otherwise it will create a file named naverrorlog.txt, which will have any errors.
type naverrorlog.txt
If you see an error that the file does not exist, it means the process isn't done. On my server it took about 15 minutes. After this was done, I tried again and it still didn't work. I went back to my object and recompiled it and I discovered that when I fixed the field name, I introduced some other field naming problem (I can't remember what) that caused my schema to not sync. I quickly fixed that but the error persisted.
At this point, I started trying all sorts of things because it was late and I was tired. If I were monkey and had poo to fling there would have been literal crap all over my screen instead of just virtual crap. Fortunately for you, the reader, you get to fast forward to the end of all the crazy and get to the part where I actually solve the problem.
After getting the table to sync, the packages that I uploaded were no longer working for me. I regenerated my symbol references again and that did the trick.
I unpublished my app because I wanted to clean some things up (before I realized I should have just incremented the version) and I had to do this again. The second time around I was able to nail down the sequence a little better. First generate the symbols, then download them and upload them as extensions with -PackageType SymbolsOnly.
In conclusion
I unpublished my app because I wanted to clean some things up (before I realized I should have just incremented the version) and I had to do this again. The second time around I was able to nail down the sequence a little better. First generate the symbols, then download them and upload them as extensions with -PackageType SymbolsOnly.
Comments
Post a Comment