I have a com dll developed in VB.net that provides an interface to eBay api's. Been working for many years. Recently eBay change certificate authority and moved to TLS 1.2. Sorted through that but now the dll seems to quit in mid transaction when called from Access. The functionality does listings from local inventory to eBay. The first part loads pictures of the listing item to eBay. That works fine. I can see the calls and responses using Fiddler. It then moves on to actually listing the item which seems to stop when called from Access. What I get back in Access is "Can't find x.dll at file location". I know the call is going to the dll because it uploads the pictures.
I have a test project developed in VB.net to test the dll and when run from that everything works. I can see the listing call and response in fiddler. When run from Access there is no listing call. I can verify that the endpoints for the calls are the same from test project or Access.
My question is how to debug the dll in the Visual Studio IDE when it is called from Access. Any thoughts?
CodePudding user response：
Yes, the way you do this is open up the vs class you have for the .dll.
Then in debug of the project, setup this:
Now, when you hit f5, then access will launch and run.
If at this point, say you close access (exit), then you note the debugging process stops.
However, go though the forms and whatever in Access, and get to the point where you hit that button or whatever.
You find now that you can say set a break point and even step and debug your .net code like any other code. So say in my example (a custom sage 300 .net interface to access), I want to debug "find customer" routine from VBA.
Well, in vb.net I have this code:
so, when any routine - even those in the class instances is called, you can set break-points etc.
And to stop? Just exit access.
So, you can make a change to your code, and even hit f5.
It not clear how you are registering your .dll (or do you use some VBA to side-load the .net - that's what I do, since it is a pain to have to register my .net com objects on each PC.
But, do give the above a try. It should let you debug your .dll code. The trick is to have VS launch ms-access as a attached debug session - and that is exactly what the above setting in your class project above allows you to do.
do note in above, I used the path to access 2010 (access 14), so replace the path name to the access.exe with your version of access you are using.
And keep in mind, that if have some installer, or some custom "thing" that registers your .net .dll for you?
Well, during this process, if your VBA assumes a registered com object, then ensure you have this check box enabled:
On compile for the project settings, you thus want this option checked:
NOTE very careful, checking the above option does not change the code or anything at all - it ONLY does a regasum automatic for you, and this would of course re-register your existing .dll - which is what we want for debugging. After you done, do run your re-register of your .dll to switch back from the debug .dll that going to be in your current project bin folder to whatever you "regular" use on your PC.
FYI: In MOST cases, I find this whole idea does NOT work unless you launch VS as administraor. So, make sure VS is being run as administraor for this to work.
I tend to just tap windows key, or even right click on your vs shortcut, and of course choose run as administraor.
This is so often required, you note that VS will EASY and quite CLEAR show you running in admin mode, and I quite much now always run VS this way.
You should see this:
