waldo: NAV Upgrade: Import and Compile crashes when NST is running

[Blog bot]

Источник: http://dynamicsuser.net/nav/b/waldo/...nst-is-running
==============

This is just a small blogpost to mention a few things you need to take into account when you’re working with objects on a large scale – I mean importing, exporting, upgrading, compiling, .. whatever.

My scenario

I was upgrading a customer from CU3 to CU8. Sure, you might wonder why it took me so long :-). Any reason is the wrong reason – I agree ;-). But anyway .. . I always use my scripts that are also available on my github here, which I have done exactly 37 times before – I counted them. So why change – this is a 10 minute job – let’s quickly do this. Basically, the script is following three major steps:

• Merge the objects
• Create a fob
  
  • Sandbox db
  • Import merged txt
  • Compile
  • Export fob
• Perform upgrade on customer db

I noticed that the import-step took far too long.. . No errors, nothing. During (quite some) investigation, I noticed that it was “hanging” on a very specific object. And always the same object.  When I stopped the NST, there was nothing hanging anymore – but obviously, this cannot be the case.. .  Even more, when importing, it automatically tried to start the NST again (???).  Strange behaviour if you ask me..

Missing DLL

It appeared to be some kind of object that used some custom dll … . I can only assume that – even when importing txt – even when importing without synchronizing schema changes – it was still trying to connect to the NST to get to the dll.

Well, on my machine, which is a general upgrade-VM I always use for all my upgrades, that specific dll was not in my Add-ins folder, so no way for the NST to find it ..and – I assume – it hangs. No error. No message. No progress .. Nothing. I noticed that when I shut down the NST, all was importing fine.

Failing objects

But then again, when compiling, I had the same issue as above. No message, it just hangs and wastes your time. Apparently, when I finally figured out it was the dll .. and copied it in the Add-Ins folder, all went fine. But a next issue came into play. During the merge, I already noticed some customer objects that were failing. Failing objects means: completely ignored during the merge-process – which means: totally not part of the result. Obviously, this does not have positive consequences to the “Compile All” routine, as there are missing objects.

In my case, apparently there ware functions and local variables without a name. Apparently, it is possible to create this in the DEV environment, only the PowerShell tools does not accept this, and completely ignores the object.

I left it as is – was going to fix it later on in the resulting database – but it made the upgrade going completely bad – at the end, I was not able to even sync my schema-changes because of (probably) too many uncompiled objects (?).. . When I decided to first handle these failed objects, and include them in my merge, all went fine again.

So .. what have I learned today?

When you upgrade, always make sure you deal with the failed objects first, before you continue in creating fob or performing the final database-upgrade

When you upgrade, always make sure that you have your custom .Net libraries ready in your Add Ins folder.

All sounds very obvious, I admit. I was just not aware at first of any custom dlls .. and I definitely wasn’t aware that it would actually going to crash and hang my process without any notice. This doesn’t really co-exist with my “only-fix-when-error”-mentality




Источник: http://dynamicsuser.net/nav/b/waldo/...nst-is-running