Problem with 'Cannot add or remove static keyword for this method'

[lkustb]

Hello everyone,

My team once introduced the BottomLine models into the system to do printing, but recently a decision was made and 3 models in ISV layer were removed with Axutil command tools to have a cleaner system, and I am cleaning the code for the left overs in the CUS layer.

Right now, everything else seems to be fine, but I have a problem with [PurchFormLetter] class and [SalesFormLetter] class. What I did was to remove a macro added at the line right above the method signature, and cleaned other stuff, but right now, there is a red line showing at the

tag, complaining that “Cannot add or remove static keyword for this method”, but I didn’t add ‘static’ method by myself, anyway.

The method icon has a green dot, but once “F7” the class, the error is shown as the picture shows.

I have done a full compile last night + removed XPPIL code + restarted the AOS, but the problem is still there.

Any advice is greatly appreciated.

Thank you,

Kun

[MartinDrab]

Try to remove the object cache as well. Also compare different layers of the method, maybe you’ll find something suspicious there.

[lkustb]

Thank you for your reply, Martin. But I have cleaned the User cache by doing

-1- In the Client “File → Tools → Options—> Usage Data”, then click “Reset”;

-2- Turn off AOS, go to Users{my user folder} \ AppData\Local, delete all “.auc” files ; go to Users{BCP account} \ AppData\Local, delete all “.auc” files; turn on AOS

Yet the problem is still the same. However, we found that the deleted ISV model used to have something changed in the classDeclaration method, in the section of parameters being packed as follows:

---

//List of parameters common for PurchFormLetter_* classes that needs to be packed

//for the correct class transition between client and server.

//If you need some additional parameters on the client, add them to this list.

//All variables in the parmListCommonCS must also be added to the method resetParmListCommonCS.

//After any changes, please increase both versions.

#define.ParentVersion(12)

#define.CurrentVersion(12)

#LOCALMACRO.ParmListCommonCS

editLinesChanged,

reArrangeNow,

enableUpdateNow,

validateAll,

callerFormName

#ENDMACRO

//List of parameters extracted from arguments for the transfer from main() to mainOnServer()

#LOCALMACRO.CachedArgsList

parmEnum,

callerFormName,

isProforma,

callerMenuItem,

className,

methodName,

mode,

(btWebReport <-----the ISV layer change that was there before I removed the ISV model using ‘Axutil’ command)

#ENDMACRO

---

-3- So, after I removed the ISV models using “Axutil” command, this packed list is changed (because btWebReport is removed), so I tried today to increase the number by 1, so it looks like

#define.ParentVersion(13)

#define.CurrentVersion(13)

** Right now, a little good thing is happening that if I go to the method and ‘F7’ that, the compile is without any problems

-4- But if I go to the [PurchFormLetter] class itself and “F7” that, it outputs like ‘compiling class’ / ‘exporting class’ / ‘checking best practice’ / ‘Errors found’

I have tried to compile the application using parallel compile, the problems is still there. However, if I go ahead with full CIL, the full CIL is not complaining the [PurchFormLetter] class.

-5- In all, changing the packed list number definitely helps to uncover what’s the root cause is, as that number should be incremented by 1 each time the list is changed, but why compile the class itself still has error? I cannot figure it out now.

Any advice is appreciated.

[MartinDrab]

It’s not enough to know that there is a compilation error. What’s the error message and what’s the related source code?

[lkustb]

Sorry not to present it in a clear way, the problem right now is with [PurchFormLetter] class. And here is a demo that shows what I am talking about: http://screencast.com/t/2yTBW9SAAxP

You can click the URL and see the screen cast video, hope this one is better.

Thank you so much!

[lkustb]

Another thing I am suspecting to cause the weird problem is as the attached picture shows, I am wondering if"Baseline database name:" entry matters how the compiler behaves? I used to have this entry as an empty one, and was told to configure as as the same database as the transnational database for code comparison use, but does it mean that it remembers the old code even if I delete the ISV models? I am now with R2+CU7, the ISV models were installed before R2, so it was a long time ago, but the ‘Baseline database name’ entry was configured in this way about 2 weeks ago.

Thank you,

[MartinDrab]

Aha, so it’s still the same error (“Cannot add or remove static keyword for this method”).

The baseline database is not used for compilation; it’s used for comparison and upgrade conflict detection. But it also makes no sense to use the “normal” database as the baseline - you can’t ever get any difference if you compare a single database with itself.

If you actually had an R1 application in an R2 system, didn’t do a proper upgrade and then even removed a layer in the middle, your system really can be in an unpredictable state.

[lkustb]

Thank you for the reply, Martin.

The reason I was told to set the transaction database as the baseline database entry was, as I was told, before R2 the code database was not separated out(as we all know), and after R2, this database is not used but it still has a legacy system, so when we set the baseline database to the transaction database itself, we can have ‘old syp’ / ‘old isv’ shown as one of the options when we do compare(just as you mentioned for comparison purpose).

My team did the R2 upgrade about 15 months ago, so far, it’s not that bad, and we recently upgraded to CU7.

I saw you mentioned that removing a model can cause problems, so, this “removing a model thing” is something you think doable? If it’s still possible to do it, I have tried to remove the ‘baseline database name’ value from the server configuration place, but I am constantly being popped with ‘it’s not a valid SQL Server’ database error. So, I want to ask if it’s possible to return this value as an empty value here?

Thank you,

[MartinDrab]

I admit I didn’t think about your scenario, i.e. that you still have the pre-upgrade model in your transactional database.

Removing a model definitely is doable, but it also can cause troubles that need addressing. If I uninstall a class from ISV and it still has changes in CUS, the state of CUS doesn’t make sense anymore. (I don’t know whether AX tools validate this scenario before uninstalling a model).

About the baseline database name - if you want to remove it and the GUI doesn’t allow that, you can remove it from Windows registry (under *HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dynamics Server\6.0*).

[lkustb]

Martin, thank you very much for answering the questions along the way. And after some investigation, a solution was found as follows:

-1- It’s beneficial to look at the “UtilIdElement” under AOT/ System documentation / UtilIdElementand “UtilElements” under AOT/System Documentation / UtilElements;

-2- Both elements in the 1st step corresponds to the Views in the model store SQL Server database, and using the “ModelElement” table in the model store database;

-3- The ‘PurchFormLetter’ class on AOT has ID of ‘481’ and ‘SalesFormLetter’ class on AOT has ID of ‘524’;

-4- Use the following SQL to query out how the ‘callPrinterSettingsFormLetter()’ methods are defined, by

select * from modelElement

where Name = ‘callprinterSettingsFormLetter’

and parentId in (‘481’, ‘524’)

we can see that the ‘ElementType’ is ‘14 ClassInstanceMethod’;

-5- It’s recommended to update them in the database by

update modelElement set ElementType = ‘13’ – ClassStaticMethod

where Name = ‘callprinterSettingsFormLetter’

and parentId in (‘481’, ‘524’)

When I reopen the AOT, the callprinterSettingsFormLetter() method on ‘SalesFormLetter’ class and ‘PurchFormLetter’ class is correctly recognized as a static method and the compile finished without any problems.

Thank you