Unable to reference System.Xml.Linq?

Has anyone else been unable to unable to add the reference to System.Xml.Linq? I explicitly added it through the assembly reference manager and it doesn’t seem to stick…
One would think that this would be a simple process.

You can only add references to dll’s that are in the Client folder… did you do that?

To add, I’m on a .NET greater than 3.5 too.

I did not, but if I copied it to my client file, would I be able to? Futhermore, I would assume that anyone who uses this would also need that assembly, so should it be included in the client install?

Correct, you can add a customization to the client install to deploy the DLL automatically. Check out my blog post on the topic

http://trigemco.com/epicor-10-client-deployment/

1 Like

Nice! Thanks

however what are you trying to do that you need that DLL? Generally you want to avoid bringing in system DLl’s in a custom fashion… if you can

Probably a dumb project, but I am making a dashboard that pulls in query data from the BP Method and BP Directive business objects (specifically the BPDirective.Body field) to format with indentation and display in a text box to the user. The idea is to better manage BPMs in the system and I was thinking this might be a way to see the contents of the BPM.

I am not sure how that would help… What would looking at that awful XML do for you? Just curious what you think it would accomplish :slight_smile:

The idea was to give a technical user an idea of what the BPM did without needing to necessarily needing to go into the BPM itself. If you have any suggestions for managing BPM’s besides a spreadsheet, I’m all ears! :grin:
I’m the only developer at my company so it’s easy for for me to understand all the changes that have been made, but when other technical staff like IT need to document and understand BPMs, I don’t have a good way for them to do so.
I was hoping that the XML would give them sort of an idea of what it does, but maybe that’s wishful thinking.

Yeah that XML is not for human eyes… I mean the best way to document BPMs for the populous is to actually document them. Write a doc that is stored in whatever system desire (DropBox? Git? etc) which you write the purpose, design and execution of each project / BPM in your system.

1 Like