At the moment we don’t have async methods in this version you could wrap them in a task
But not at the moment I’ll see if we can make the repo public
1 Like
@josecgomez I pulled the code using the “Go To Definition” disassembly within Visual Studio. I was able to test an Async version of a method today. Works great. I would like to contribute what I’m working on so others can also have clean responsive GUIs with no deadlocks.
2 Likes
@josecgomez … you might recall conversations we had a long while ago regarding V1 and sessions – issues we were having regarding license management when making volume runs. We implemented the “EpicorSession” object and managed the session disposition in code manually.
I don’t see that object in V2. Can you talk about how that is managed in V2 please?
[After exploring a bit, I do see a new object “EpicorRestSession” – is that a direct substitute?]
Thanks! 
I believe we made it so that if you wrap your call in a session instance it will dispose let me find an example
See the example on the original post above near the bottom
When we try to manage the sessions across calls, we want to call the EpicorRestSession into an object and then manually call Dispose on it some time later…
…vs. doing it via using(…) as you show in your example above 
.
However, when we try to do that, we get an exception in it’s constructor:
"Cannot convert null to 'System.Guid' because it is a non-nullable value type"
Any idea?
Just put it in an using
using (EpicorRestSession ses = new EpicorRestSession())
{
//Do all the things here!
}
Does that not work?
We can’t do it that way, because of how the Epicor licensing works – it consumes too many licenses for the number of calls we make. In V1 we saved the session in a session variable and then make all our REST API calls for the action we’re running (across different independent methods), then dispose it when we’re done.
How would it consume multiple licenses when you are using the same license? #Confused…
You can if you want to just do
EpicorRestSession ses = new EpicorRestSession();
//Do all your Epicor stuff
ses.Dispose();
Yep. That’s exactly what we’re doing.
RE: Licensing … I dunno. You and I went round and round with this in V1 times. If I didn’t wrap it all in a single session, all the web licenses would get consumed “one per call” and didn’t “timeout” fast enough, so we’d run out of licenses. The session method as I described was the solution.
Okay, the above code should work then.
Dunno. It doesn’t … it throws the exception I included there.
at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
at EpicorRestAPI.EpicorRestSession..ctor()
Don’t have visibility beyond that.
[UPDATE: Found the issue – it’s an uncaught error associated with an invalid CompanyID value.]
1 Like
So I wonder if your session is not returning correctly… All it does is process the GUID back from the session.
I wonder if they changed what the method returns in 2022… Let me check.
UPDATE: are you guys now using Epicor SSO ID?
Ah yes you need to set the company first on the REST Settings with a value that matches the user
1 Like
I didn’t see any details in the exception regarding that. Not something that we can capture cleanly? I guess it’s not that important since it is only set once really.
Well – thanks for helping me suss it out.
1 Like
FYI using the latest version of RestSharp breaks this, get a typeloadexception … downgraded and it went away
The library is version specific like most DLL dependencies.
yeah, I just saw a security warning, so I let it upgrade to the newest. It broke, so I just downgraded until the library still worked but the security warning was gone 
2 Likes
The extensions I am working on provide compatibility with the latest RestSharp. My version is starting to become radically different than the original package. Due to the lack of open source on this project I’m trying to decide if I should completely rewrite this tool. I started with the intent of contributing to upstream but the farther I get from it, the harder that becomes.
1 Like
If you want to enhance it we would take a PR but if you are just re-writing the whole thing then do you either way works 
We don’t have it open sourced because we are trying to keep some control of it , we are not looking for it to baloon the first version we tried to open and everyone wanted to write very specific functions for each Epicor method and that was just not the direction we wanted to go.
If your goal is to add async methods and enhance the library without fundamentally altering it then we would certainly take a PR send me a message PM with your github username and I’ll give you access so you can clone the repo if you’d like.
Another thing to keep in mind is that the version of RestSharp we are using is purposely compatible with the Epicor Client through 2021.X+ because we wanted to be able to use this library within Epicor if we needed to.
2 Likes
is PR public repo?