ISV Software Solution Test Guidelines - What the Hell?

Tommy_Schou

Hi

We are currently in the process of getting a Dynamics NAV addon certified through lionbridge.

On one point we have found what we believe MUST be an error in their testing procedure so I would like to know if anyone else has come across this. All our objects are marked in the version list according to:

"Standard Microsoft Dynamics NAV version convension"

BUT and this is apparantly a big but. Our objects do NOT have the modify flag set to YES. Modified is set to NO which should be obvious to anyone is the correct way to do it. (Unless i missed the latest way to get more money out of customers when upgrading an addon).

But according to this:

http://www.lionbridge.com/dynamics/Micr ... 09-SP1.pdf" - Page 17

TEST METHODOLOGY
To verify this requirement, the test vendor will follow these steps:
1. Check that the version list of new and customized objects is consistent. If standard Microsoft
Dynamics NAV objects have been modified, then you must mark the modifications with a code
and version number. The Modify flag for the specified object must be set to Yes.

The above states that objects must be marked with YES in the modify flag? This is a change in the lastest test-guidelines for 2009 SP1. In 2009 it was stated that Modify flag most be set to NO (The correct way).

Has anyone else come across this issue with getting an addon certified?

matttrax

Never gone through it, but setting modified to Yes or No is a personal preference. Yes, the last time I read the NAV Development documentation it said you should uncheck the modified flag when deploying (so you could basically just filter in your dev environment for what was modified, export and import it).

I can't stand that, honestly. If I'm look at a customer's database, I want to easily know that an object has been changed. You can't filter on every possible version tag someone could have used. And what if they forget to add a version tag? Or just don't use them.

To me, their documentation makes perfect sense. You have changed a base object. Therefore that object has been modified and the modified flag should be checked.

Anyway, I know it's not quite what you were asking, but the "to check or not to check the modified flag" debate could go on forever.

Tommy_Schou

matttrax wrote:

Never gone through it, but setting modified to Yes or No is a personal preference. Yes, the last time I read the NAV Development documentation it said you should uncheck the modified flag when deploying (so you could basically just filter in your dev environment for what was modified, export and import it).

I can't stand that, honestly. If I'm look at a customer's database, I want to easily know that an object has been changed. You can't filter on every possible version tag someone could have used. And what if they forget to add a version tag? Or just don't use them.

To me, their documentation makes perfect sense. You have changed a base object. Therefore that object has been modified and the modified flag should be checked.

Anyway, I know it's not quite what you were asking, but the "to check or not to check the modified flag" debate could go on forever.

Look at it this way. You are the developer of an addon called MyAddon. Your versionlist is MA1.00.

You make a change in Table 81 and alter the version list to include MA1.00 and leave the checkmark in "Modified".

Versionlist : "NAVW16.00.01,MA1.00"

You send this to all your dealers who install it in lets say 1.000 solution. All 1000 solutions now have a Table 81 with a checkmark in modified AND a version list: "NAVW16.00.01,MA1.00"

You now create a new version of MyAddon. Let's call this version 2.00 :-) and your new version list now says:

"NAVW16.00.01,MA2.00"

You send this to your dealers and they implement it in their 1000 solutions. When they import your version 2 object they will get a conflict in the NAV import worksheet because you left "Modified" checked and they will have to manually figure out what the differences are between the two versions and correct the code accordingly. Imagine a solution where you changed 30 standard objects. You will have to do this for 30 x 1000 objects to upgrade your entire customer base. Excellent for revenue but really bad compared to what you could do if you had UNCHECKED "Modified".

Had you done this you could import the new version and NAV would check the two version lists:

Old version: "NAVW16.00.01,MA1.00"
New Version: "NAVW16.00.01,MA2.00"

NAV would conclude that there are no conflicts and import the object automatically. You just saved your customers 30 x however long it would take you to manually merge the two versions of the standard objects. Had the customer (or another ISV) made his own changes to Table 81 it would now have a checkmark in "Modified" and the import worksheet would correctly report a conflict.

Not to bash you or anything but saying that you should leave Modify Checked (after correctly altering the version list) is just plain wrong :-).

David_Singleton

I am definitely with Tommy on this.

The way it has always worked is that the MODFIY flag means that the code in this object is DIFFERENT to what the version list says. Once the version list is updated, then you un-tick the modified flag.

The object import will look at both fields, so every option is covered this way.

I think this new method is wrong, and probably introduced by some one new at Microsoft without really knowing the full implications of this in the real world.

I think its critical that during object import that the person doing it if there is any conflict, then YES they need to review the object version list in deatail and then the code to work out the differences.

David_Singleton

Lets take this a step further, and ont he basis of this new philosophy, at what level should an object be considered to be modified.

1/ First release at W1
2/ SP on W1
3/ hot fix on W1
4/ New version of W1
5/ Local release (eg NA)
6/ Local hot fix
7/ Add on
8 / new release of add on
9 / partner modification
10 / New update from partner
11/ Customer modifications

etc etc.

To arbitrarily pick 7 as the point is wrong. We would have to say that the first time an object is every released on W1 it is not modified, and then after every change leave the tick box modified.

It really needs to be that if the version list is updated, then the tick box is marked as unmodified, because that version is new and not modified, but when someone changes that version it then it is modified.

matttrax

No offense taken by me. Like I said, you'll find varying opinions on what is right and what is wrong.

Although I have worked for an add-on developer in the past it was a little different. Companies didn't have custom mods, just the add-on. And I never did any deployment for it.

Even if there was a conflict, couldn't you just let NAV do the merge for you? I don't use it often so I don't know how good it is. Just thinking out loud. Don't want to stray from your original question.

Like I said, I'm not often upgrading add-ons unless the whole system is being upgraded, at which point I would do a code comparison anyway. I will say this, though...when I have worked for partners I've always been told NOT to uncheck the modified flag...right or wrong.

[Edit] Of course they never really enforced the version tagging either, so I have that bad habit. Probably don't see the conflicts nearly as much.

Tommy_Schou

matttrax wrote:

No offense taken by me. Like I said, you'll find varying opinions on what is right and what is wrong.

Although I have worked for an add-on developer in the past it was a little different. Companies didn't have custom mods, just the add-on. And I never did any deployment for it.

Even if there was a conflict, couldn't you just let NAV do the merge for you? I don't use it often so I don't know how good it is. Just thinking out loud. Don't want to stray from your original question.

Like I said, I'm not often upgrading add-ons unless the whole system is being upgraded, at which point I would do a code comparison anyway. I will say this, though...when I have worked for partners I've always been told NOT to uncheck the modified flag...right or wrong.

[Edit] Of course they never really enforced the version tagging either, so I have that bad habit. Probably don't see the conflicts nearly as much.

I have come across ISV's before who does the same thing and I try to convert them every time :-)

Now I just need to get Microsoft to correct their procedure for certifying add-on products. Just don't know who to turn to get that changed. I foresee that will be quite a task. *sigh*

I would still like to hear if anyone has come across this issue while certifying an add-on product.

matttrax

I would call up Microsoft. Every time I've called the NAV team directly they've been really helpful. In the US at least it's actually people that work for Microsoft, not some outsourced company like the rest of MS support.

They may at least be able to point you in the right direction.