Would Epicor provide source code for DMT?

I am making no head-way on a DMT template that Epicor knows is not working. Rather than waiting for them to fix it (now over 1 month with no end in sight), does any know if they would provide the source to fix it myself?

I know at one time, Epicor would provide source if you signed a waiver and presented it to the CAM. Just curious if this same process works for the 3rd party products.

Or since DMT comes with “Epicor.DMT.Lib.dll” (I assume this is where the templates are stored), can I just use Reflector for decompiling/fixing/recompiling??

No they are not going to give you their source code for DMT. You can buy the source code of a LOT of Epicor by purchasing the SDK.

Possible to de-compile/re-compile using another tool like NET Reflector? I am certain it is just a typo or something simple bc it worked in other versions (just not 10.2.300).
(I have given-up on DMT Development saying "we are working on it ").

The short answer is yes, you can. That’s a tall mountain to climb. A more navigable trip might be to identify a specific shortcoming of DMT, then write a custom solution just for that particular issue.

Possible Options:

Also its quite possible that certain template you are using incorrectly. Even if you decompile, you can only look at the logic, I wouldnt attempt to modify it since most of it is obfuscated. We are currently implementing Epicor and have been for 5+ years at 20+ locations and part of a Cut-Over is to DMT in data from AS/400 IBM Systems, Microsoft Dynamics etc… into Epicor; we haven’t really found any show-stoppers.

But Epicor comes with a RESTful API nowadays, you can fix it writing some REST Client or even using Updatable Dashboards and I think Excel even lets you connect to a Data Source.

You can also report your bug, issue here on the forum - see what the community makes of it. Epicor is watching this forum, even one of the DMT Creators Mr. Edginton @Edge is part of this forum (former DotNetIT) and today VP of Development at Epicor.

Also as a headsup I see you are a consultant I’m gonna throw out there that de-compiling (though more importantly) recompiling a commercial product to use with one of your customers is generally frowned upon and can potentially land you in hot water.
Also most of Epicor’s DLL’s are signed and when you re-compile them you will be lacking the ability to re-sign them so that they work (load) into the exe properly.
I suggest hammering support some more regarding this issue and as @hasokeric pointed out Epicor watches this forum and you’ll hopefully see results.

Also can you give us more specifics as to which “template” is failing for you? We may be able to replicate the issue and add pressure (if needed) or find a work around for you.


4 posts were split to a new topic: Musings Regarding Haso

did you consider just finding a workaround to the DMT problem? importing as two lists? Updating from a Dashboard (Copy/Paste)? sometimes the path of least resistance is just walking around it.


Thanks Jose.

“Epicor DLL’s are signed” was enough for me to not waste too much of my time. I still might use NET Reflector to at least identify the issue to Epicor.

I have thought of a workaround to pump data into either some “never-used” or some custom fields, then have Post-Processing Update BPM directive take that data and update the correct fields.
I have made zero head-way with DMT Development and they no longer respond to my follow-up messages.
The Call has existed since December 21st (almost 6 weeks).
Customer has lost all confidence/faith a resolution will be provided.

Response goes as follows:

_"Hello Thomas, _
Development doesn’t contact customer, the contact point will be Tech Support.
I can push Development to provide any update, but at this point, it is on Development side, currently being worked to get a resolution for this. I’ll place the case as Suggested Resolution (Not Closed) since, once again, the issue was reported to Development and it is on their side. The case will remain open for 3 more weeks. "

If you provide us with the issue we may find a work around :slight_smile:
What’s the actual problem?

1 Like

I concur with Jose - What’s the issue you are seeing. As with most technologists, we hate being told how to do something but rather prefer being told what the issue is to help solve the problem. :wink:

As to the de-compiling - De-compiling and recompiling is a big no no when you are making money off something. In most licensing scenarios, get a good lawyer. For education though only the foolish try to block you these days.

Software is often used in ways unintended from initial design and bugs occur when surprise use cases hit code not defended against surprise data. It’s common. I’ve de-compiled and sent bug reports on to MSFT for 18 years on various platforms - now easier with most of MSFT being open source.

I have received more than my fair share of code snippets in ICE and ERP code from many up here among other locations. It does help me find a line number in a file faster and I have helped to speed triage on tickets more than once when the due diligence has been done by a partner or customer. That’s just being efficient as a business and professional and an appreciation for the customers extra effort.

Not every scenario can play out that way of course. Many times we will get a how to fix the issue that causes more side effects than the original report. I respect that many just want the immediate fix for their explicit issue but side effects are notorious for annoying developers and customers alike. I don’t know the issue you are discussing. I have not been a part of the DMT team and rarely get to play with ERP anymore but that doesn’t mean I don’t help out where I can - even it it’s just vectoring folks to the correct resource.