Whether you like it or not, if you want to be a succesful Dynamics NAV developer in the future you have to understand PowerShell. So do I.
Currently I am working on an integration project where we make an interface between an external solution and NAV using WebServices. Idea is to ship the software with Delta files instead of a fob.
So I am running my PowerShell and notice some differences between NAV2013R2 and NAV2015.
This is what I run:
NAV2013R2:
$MergeResult = Update-NAVApplicationObject -Target “C:\Users\Marije Brummel\Documents\DynamicsNAVNA71\Files\” `
-Delta “C:\Users\Marije Brummel\Documents\Delta\” `
-Result “C:\Users\Marije Brummel\Documents\New Object\” -Force
NAV2015
$MergeResult = Update-NAVApplicationObject -TargetPath “C:\Users\Marije Brummel\Documents\DynamicsNAVNA80\Files\” `
-DeltaPath “C:\Users\Marije Brummel\Documents\Delta\” `
-ResultPath “C:\Users\Marije Brummel\Documents\New Object 80\” -Force
As you can see the parameters have changed, but so has the resultset.
Unfortunately there is not much documentation on the resultset, only on the cmdlet parameters.
But I ran into a video from Bas Graaf taht shows this:
$MergeResult | Get-Member
This returns a list with the object members.
NAV2013R2:
Name MemberType Definition
—- ———- ———-
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
Conflict Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Conflict {get;}
Error Property Microsoft.Dynamics.Nav.Model.Tools.ErrorInfo Error {get;}
Id Property int Id {get;}
ObjectType Property string ObjectType {get;}
Result Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Result {get;}
UpdateResult Property Microsoft.Dynamics.Nav.Model.Tools.UpdateResult UpdateResult {get;}
NAV2015:
Name MemberType Definition
—- ———- ———-
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
PSPath NoteProperty System.String PSPath=C:\Users\Marije Brummel\Documents\New Object 80\COD84001.TXT
Conflict Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Conflict {get;}
Error Property Microsoft.Dynamics.Nav.Model.Tools.ErrorInfo Error {get;}
Id Property int Id {get;}
ObjectType Property string ObjectType {get;}
Result Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Result {get;}
UpdateResult Property Microsoft.Dynamics.Nav.Model.Tools.UpdateResult UpdateResult {get;}
So as you can see (I hope) the Path is missing in NAV2013R2.
What I ended up doing is using the NAV2015 cmdlet for NAV2013R2 objects. There is probably a smart way to figure out a filename from the other properties.
Challenge for someone?
Marije
didn’t try it in 2013, but just a guess…
the “result” property is a member of “Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo”.
The ‘ToString’ is just an implemented interface, which is going to get the path from the “result” property. Apparently this was not yet implemented in 2013? dunno…
My guess is that you should always get your path with:
$MergeResult.Result.Filename
LikeLiked by 1 person
OK, I was wrong .. ToString hasn’t changed .. didn’t read it correctly.
But indeed, the PSPath-property has been implemented.
But still: “$MergeResult.Result.Filename” should work in both cases…
LikeLike