-
Notifications
You must be signed in to change notification settings - Fork 247
Frequently Asked Questions
Please start by having a look at our app development landing page located at https://msdn.microsoft.com/en-us/dynamics-nav/developer/devenv-develop-apps-for-fin and follow the step by step guidelines to get set up. You can then have a look at the Getting Started section of the developer documentation: https://msdn.microsoft.com/en-us/dynamics-nav/developer/devenv-get-started
Our blog post series provides a good overview for features that were added in each month: https://blogs.msdn.microsoft.com/nav/2017/10/12/nav-development-preview-october-update/
- For NAV 2018 you should use the AL Language extension that is installed together with the product (minimum version 0.12.XXX).
- For the Cloud sandboxes you should use the AL Language extension available on the VS Code Marketplace.
- For latest Developer Preview releases you should use the AL Language extension that is available on the docker images.
https://docs.microsoft.com/en-gb/dynamics-nav/developer/devenv-debugging
Two primary purposes of menusuites are to:
- Make pages searchable
- Make pages accessible through a navigation structure
The first purpose can be achieved in extensions V2 by using the new properties added to Pages and Reports. See this blog post for more details: https://blogs.msdn.microsoft.com/nav/2017/12/06/nav-development-preview-december-update/
The second purpose can be achieved by extending the Navigation Pane page and/or by adding Actions to other existing pages that can serve as a navigation starting point. See Extending Navigation Pane #669 for an example.
See the following documentation topics: https://docs.microsoft.com/en-us/dynamics-nav/developer/devenv-upgrading-extensions https://docs.microsoft.com/en-us/dynamics-nav/developer/devenv-upgrade-v1-to-v2-overview
The comment on the following issue also contains useful information Issue #721
Code that relied on temporary files needs to be rewritten to rely on InStream and OutStream types. Code that relied on permanent files needs to be rewritten to use another form of permanent storage.
We are considering a virtualized temporary file system to make working with temporary files available in the cloud in the future.
On-Premise:
DotNet interop will be available at some point in the future but not in the NAV release this year.
SaaS:
DotNet interop is not available due to safety issues in running arbitrary .NET code on cloud servers.
There are at least 2 possibilities that we recommend:
-
With each monthly update we are providing new AL types that replace the most typical usages of .NET like HTTP, JSON, XML, StringBuilder, Dictionaries and Lists. Many .NET usages can be replaced directly by these new AL types resulting in much cleaner code. Documentation: https://msdn.microsoft.com/en-us/dynamics-nav/developer/devenv-restapi-overview
-
For things not possible to achieve in AL code we recommend using Azure Functions to host the DLL or C# code previously embedded in NAV and call that service from AL I recommend the following blog posts from our MVPs to understand it in more depth: http://vjeko.com/state-net-affairs/
http://www.kauffmann.nl/2017/06/24/al-support-for-rest-web-services/
http://vjeko.com/invoking-azure-functions-al/ -
We offer an open source GitHub repository where you can submit .NET type wrappers that, if accepted, will be included in the base application: https://github.com/Microsoft/cal-open-library
We have blocked off a certain set of functions from being directly called from Extension code. The approach was based on a conservative static analysis resulting in some functions being blocked unnecessarily. If you require to use one or more of these functions please log an issue and provide a full list. We will analyze the request and unblock functions deemed safe.
Short answer: Only selected features. Longer answer: features in the development tools often depend on corresponding server changes/capabilities. Therefore, in many cases, back-porting dev environment features would mean back-porting server features. If these in turn depend on other features we quickly get into fully fledged development effort for an additional product. (And the problem would keep growing over time, with each following On-Prem version to maintain).
We have instead decided to focus the development efforts on a single, latest version of the product. This of course means that the new features light-up first in the cloud releases (which are shipped on a monthly basis) but eventually they will all be available in the next On-Prem release.
As a bit of technical background - codebase between D365 and On-Prem is in fact the same but only at the time of the release. I.e. D365 as of December 1st corresponded to NAV 2018. However, after the release the On-Prem product is branched for maintenance mode. Therefore any feature development in the branched product version comes at an additional cost. The proposal to release On-Prem version on a more frequent basis, in sync with the cloud version is something that we are aware of but it is a bigger, product-wise decision that will not be retro-actively made for NAV 2018. Such a decision would also have significant support, upgrade and development process consequences that need to be considered in a context broader than dev tools.
Having said that, we will back-port selected features to NAV 2018 but it will be a case by case decision dependent on the costs/benefits of doing so. It will mean finding a balance between fixing truly blocking issues on NAV 2018 vs completing new feature development for the latest version (for example, we will be back-porting the fix for #62 to NAV 2018).
We use labels both for categorizing issues into types as well as tracking the issue lifecycle.
Issues fall into the following types:
- investigate - issue requires further investigation, not clear yet if it's a bug or an environment-specific issue
- question - question about functionality, not a product defect
- bug - product defect
- enhancement - a functional change/improvement to an existing feature area
- suggestion - larger suggestion, something we might want to consider in the future
- event-request - request for a new event
- function-expose - request to mark a function as external
- V1-blocker - if the particular issue blocks conversion of an existing V1 App
The lifecycle for issues is (mix of label + milestone + open/closed state):
- input-needed - we need more information about the problem from the author
- accepted - we accepted the issue for development
- ships-in-future-update + milestone marked - the issue was fixed in our source code repository and ships in the marked Milestone
- Closed and delivered - when the issue shipped in a public Dev Preview release