Because they use this dashboard a lot in the course of their daily work, I decided to roll the changes back until I find a way to update without causing problems.
Deleted BAQ PartLocator
Copied PartLocatorBACKUP to new: PartLocator
Opened dashboard dev editor
Closed & Reopened Epicor
Once again, the dashboard is behaving normally for me.
Same as before, but no Non Nettable Qty column.
Once again, my warehouse users are throwing the same error.
I need to figure out what is going wrong right away, because several users depend heavily on this dashboard.
I don’t understand what wrong turn I may have made. This update was one I tested thoroughly.
I noticed that the error message refers to Ice.UI.App.PartLocator_5
while this dashboard’s entry in Menu Maintenance refers to Program: Ice.UI.App.PartLocator.dll.
Could that be any kind of clue?
Or could Ice.UI.App.PartLocator_5 be just an alias - not materially different from the definition I intended to use?
Neither I nor the fellow in the next cube are throwing this error. Only some users downstairs.
I already checked customizations/personalizations, and there are no personal/named files to delete.
That would be the name of the deployed dashboard. Have you redeployed it since making the changes?
Also, I had deployed a dashboard once, and it created a new file with a suffix after the name. Something like Ice.UI.App.CK_ShippingSchedule_1.dll when it should have been
Ice.UI.App.CK_ShippingSchedule.dll. So obviously the dashboard wasn’t actually running the updated version.
I deployed after adding the Non Nettable Qty column to the grid.
Then I deployed after rolling back that change.
I understand that the Program: entry in Menu Maintenance indicates the dashboard definition Epicor uses to open the app. I have wondered before whether it’s possible that Menu Maintenance is not “looking” in the right place, in order to find my newly created dashboard definitions. But I wouldn’t know how to test that, to find out.
Focus on the fact that there are different versions ("_1", “_5”, etc…) of that dll being created when you deploy (make the dashboard assembly). Look at both the files on the server and on the client machine. Ideally the DLL with no suffix, should have the newest date.
Look at both the files on the server and on the client machine.
I found the files on the client machine (more or less the same path as in your screen shot). They appear to be automatically versioned, as in your example.
Unfortunately, I don’t know where to find a counterpart to this folder on the server.
In principle, I think I get what you’re saying. Open up Menu Maintenance, and you’ll see the plain name of the dashboard in the definition file (e.g. Ice.UI.App.PartLocator) rather than something that’s auto-versioned up (e.g. Ice.UI.App.PartLocator_1).
Does Epicor default to versioning these definition files this way?
Can it be configured to map to the highest-numbered dll (rather than the suffix-free one) by default?
Is manually mapping to dashboard def files a necessary final step, every time (after the first time) that we deploy a dashboard?
I was curious last week, and experimented with this, to see whether I could “Browse” for a Program to use in Menu Maintenance. As you can see, the Program button is greyed out, like the text field beside it. If the selected Program Type is other than Dashboard-Assembly, then browsing is supported for the Program field.
I never got a straight answer as to whether the “_xx” suffix was an intended version control feature, or if it was some sort of bug. No one ever seems to mention that you have to update the menu maintenance after redeploying.
My guess would be that the deployment process is supposed to write over the existing DLL. But something goes awry and the best the depolyment process can do is to make the DLL file with the suffix. Some evidence supporting this theory, is the fact that there aren’t tons of DLL’s with the suffix, even though you know you’ve redeployed DB’s many times.
I think my solution was to rename the unsuffixed file as Ice.UI.App.xxxxx.BAK.DLL and change the name of the newest DLL (the whose date & time matches the XML file) by removing the suffix.
This is great insight, and I really appreciate it. If it takes me editing filenames in order for Epicor to actually find the dashboard definitions it’s looking up, then that will become a part of my dashboard deployment procedure. I want this to be as repeatable and predictable as it can be.
Right now, I’m working on finding the folder where these dashboard definitions are saved on the server side. I realize that’s a question best addressed to someone within this company. Our hardware man was at least able to help me log into the virtual machine.
Have the users close Epicor, then delete the data folder under %programdata%/Epicor on each machine.
The folder will be recreated the next time Epicor is logged into and will download from the server the correct dashboard definition. I call it Forced Clear Client Cache and find it necessary when changes to dashboards and customizations aren’t realized on a client machine…