Sharing my 1300 lines of code

Visual Studio for sure (have to add references tho) and apparently VS Code too:

I would wager there’s a Sublime Text plugin for .Net assembly autocomplete as well.

Mark W.

1 Like

But why use VS Code if you already have Visual Studio? (And since you can get VS Community for free…why ever?)

This thread is a perfect example of how it is confusing for product management to decide on jumping in with both feet on any particular ide. Choose anything and you disappoint 2/3s of the audience. :confused:


Because VS code is super light weight , quick and has support for a lot more languages, platforms and plugins. VCode is an Editor while VS is an IDE

1 Like

While VS Community is free for many, the actual terms are:

If you are an enterprise, your employees and contractors may not use the software to develop or test your applications, except for: (i) open source; (ii) Visual Studio extensions; (iii) device drivers for the Windows operating system; and, (iv) education purposes as permitted above.

An “enterprise” is any organization and its affiliates who collectively have either (a) more than 250 PCs or users or (b) one million U.S. dollars (or the equivalent in other currencies) in annual revenues, and “affiliates” means those entities that control (via majority ownership), are controlled by, or are under common control with an organization.

So our company, which licenses VS because we also write software for our own product, CANNOT use VS for free. VS Code is open source and follows typical Open Source rules and like Sublime Text, it runs on Windows, MacOS, and Linux.

To @Bart_Elia’s point, the choice of an IDE is a bit of a religious topic. Before you know it, we’re arguing tabs vs spaces or which line the ‘{’ should go on. What Epicor COULD do is make the editing portion plugable. When there is code editing, pass the code chunk to an Editor of choice (including the current editor which has some nice built-in testing features) and upon save from the external editor, verify the code and return to the customization environment. There are currently several different code editing methods within Epicor (UD-Method, BPMs, Customization, Electronic Interfaces, and eventually Kinetic customization of some kind) and having a plugable architecture would provide a way to create a single editing method across all these places and maybe provide some Source Control integration. Hint. Hint. :smirk:

Mark W.


The next line! and if you don’t do it that way you are the devil incarnate! lol


Sublime / VS Code / what ever…if the code editor gets intellisense I will do a happy dance :grinning:

The ability to customize Epicor is one of its great strengths and a sub-optimal code editor reduces that value…



You can get auto complete in an editor you just need to add the right references… maybe I’ll make a video about it at some point if I have time.


Bit late to the Party here, but I’ve played with Sub and VS Code, a comment my Son raised between the two is that Code is certainly being developed more. But that might be the fact that Sublime is a more mature.

On the point about linking assemblies the post on LinqPad is great and it works well without too much mind bending to understand.

The script editor has long been a bain. For some reason at the moment I can’t double click on text to select it all, which I am sure I could do in 9.

I don’t think there is too much value in Epicor re-inventing the wheel, as @Mark_Wonsil said but a plugin to VS-Code or Sublime would be a great value add, and much less effort. The downside is the fact that you end up relying on others maintaining the companion product. Particularly in Open Source where popularity of things tend to ebb and flow. A good example of this is good old Baseflight software for quad copters, Forks and branches all over the shop!. There could be a challenge for Epicor to keep the link up to date, if that makes sense.

An example of what I am rambling about is where websites rely on third party libraries and for some particular reason the site hosting the library is compromised, any sites using the hosted code, either stop functioning or become vunerable…I guess you could argue that proper development procedures and practices should be able to mitigate those circumstances…

I do like the Plugin idea very much.

By the way I think { should go on a new line :slight_smile:

1 Like

Hey Jose.

After this thread, I decide to try out VS Code. So far it looks great.

However, I’m lost with trying to add references to Epicor DLLs.

Any pointers or links on how to do this. The instructions I’ve read so far recommend using NuGet Package Manager but certain parts of the instructions do not work for my environment.

Joe Rojas

Epicor Application Manager


+1.508.597.1392 **Phone
**+1.774.826.9245 Mobile

1 Like

I opened the “client” folder in VS Code and then created a new file and pasted in the customization code
It kinda sorta did intellisense but with a whole lot of non pertinent hints…

1 Like

@Bart_Elia so you are with the Sublime Team on this post right? Just want to get the record straight. You with me or Jose. :slight_smile:

IDK @hasokeric @Bart_Elia is all M$ all the way! I’d put money on VCode… though maybe I’m wrong.

@Bart_Elia is Switzerland.

1 Like


I am Switzerland at this point.

I never got into Sublime since I don’t do any web dev - I am a total wire and server geek. It doesn’t do anything for me over VSCode or even Notepad++ for my day to day - not a criticism, just not something I use :wink:

I love Visual Studio and did a lot of plug-ins and wizards in it for a prior product but MS has not made it easy over the years. The instability of the APIs and changing tech makes it a pain. For someone that has a hand in the management side - keeping track of builds, work items, the whole VSTS side of things - that is extremely efficient. If you fit into that camp, there are some great benefits to it as an all in one Product Development toolkit.

The VS Code camp is an interesting one. Since it’s Open Source it is very intriguing (Was actually started by the guy who invented Eclipse - count that as a pro or con in your own mind). Since it’s OS, a company can take a less risky bet on it - they can always fork and maintain it themselves in case of abandonment like many have suffered through with VS. Of course to many in many companies, that’s a negative and not the positive I count it as. I understand those concerns, just disagree with the mindset - OS is here to stay and companies who embrace that in some fashion and lead will benefit - Anyone catch that MSFT had 19,000 Pull Requests on .NET Core? Lots of ‘free’ dev effort.

The biggest issue I have is migration concerns. I am a dev and love my code editor and more importantly debugger. But the more granular access you have to an API means more pain and suffering as releases occur. Keeping folks able to migrate with confidence is critical to us. I have heard nothing but cheering from folks about installing patch releases by and large. Good, I know we have more work to do but the hot fix approach is not sustainable or reliable so having the rolling patches is a must first step. Tackling the next level is a large concern and focus. Doing more and more in house with ‘Upgrade Services’ / Cirrus provides some wonderful telemetry and feedback quickly. So there is more innovation coming in that area.

Sure, easier especially with REST endpoints. Mock up integration’s in Postman, save as tests and playback on new releases. Easier and limited scope.

Those snippets in a variety of editors are rather limited in scope, easily whitelisted, easy to parse, etc.

BPM Actions?
Those widgets with their outlook rule style is again easy to parse and scope so migrating is pretty darned good. You can even set a break point and look at the code underneath - we could do a lot in this area but looks like the best after ‘Integration via Postman’ so far.

C# BPMs?
Ouch. Security concerns, migration concerns. We all have gone thru the ABL to C# 9 to 10 and it’s not pleasant. Some of discussed a proprietary language here and that is possible but that’s a lot of maintenance to pay for something that is not what most want - to set a break point in their tool of choice and step thru code. Minimizing the code that NEEDS to be written is critical here. Note the BPM Fill / Query widgets as a probable approach to continue minimizing the amount of code that needs writing.

Clients -
The largest topic is always the client. I have never been a big believer in heavy UIs. I started in distributed systems day 1 - Real time robotics and data acquisitions laboratory systems. The ‘UI’ was any device throwing data across the network. Central control and monitoring? Meh. The real effort is getting 100s of chromatography, Mass Spectrometry or robotic arms talking and listening to capture data and crunch it all in real time. That’s fun code :wink:
So when digging into message loops in MFC or dragging text boxes around to bind to some infoset in VB, Delphi, .NET, a web page… it just doesn’t do it for me personally :slight_smile:
(That and my wife being a graphic designer / web dev - she shakes her head in disgust at my UIs.)
But folks still need to change things and E10 has … nine different clients? … but everyone wants to change something and they all love their tool of preference so it’s the largest area of concern. It’s certainly a huge discussion topic in Kinetic.


Epicor should follow suit! LoL

1 Like

To be honest those discussions have occurred - they probably are in every company. It’s not that simple though. Even MSFT does not open source Windows or Office for example, ‘just’ .NET and other items.

If you are going to make that kind of change, it’s not minimal. You need a serious outreach to the community and organization, how to handle the PR approval process, security checking, triaging submission priorities… It’s a massive change of business models around your budget and staffing needs.

I think some form will happen eventually - in all companies - the questions around when and what is probably a better discussion.

1 Like

@Bart_Elia reminds us, “Dependency is one of the most critical problems in software development.” The more we decouple our software, the easier it is to test and change.

I’d love to see some path for Continuous Integration with Epicor where I can “check-in code”, have it “compile”, run a test suite, and install it into the environment. This would be a HUGH time saver for the Cloud Team where they have to do things manually. (This would include UD Field additions as well AppServer maintenance). On prem users who have to comply with SOX will be able to not give devs admin access too.

Mark W.

I think we call it BPM ducks

No argument that there is interest in some form of change control monitoring similar to what devs are used to in a VSTS pipeline or similar. As legalities around the world add requirements - ITAR, GDPR, in the past HIPAA, etc. They are trending towards more and more regulation of what IT does on a daily basis - and what is considered ‘code’.

I’ve said before that the industry is massively young and immature. I was raised with a Mechanical Engineer father - building bridges, building, boats has been done for hundreds and thousands of years. We don’t know how to stop soiling our diapers according to him and his compatriots.

Increased regulation is growing and will continue - that’s a reality. I’m not a fan of sitting with lawyers going over code (that’s a past like I prefer to avoid again) but some form will continue to be a need.

1 Like