Hum, I don’t think this would work well even if you did get this to work.
Have you ever pasted VBA code into the Visual Studio editor? The results are VERY poor. You don’t’ get VBA syntax checking, you don’t get intel-sense (autocomplete), and the VS IDE has no awareness of any of the other functions and code you have. So, even typing in the name of some sub or function? You don't get in the editor any intel-sense like you would in the VBA editor.
So, I fail to see any kind of benefit here?
If VS and it’s IDE could be made aware of VBA code and functions, and do syntax checking, then this would be a great idea. However, all you going to get is a nice text editor, and NOT a code editor.
So, my view on this matter is to use VS for extending Access, and VBA. So, such types of code can and should be written in .net code.
A good example? Access out of the box can produce PDF files (from reports etc.). However, Access does not have the ability to take several PDF’s and merge them.
While a few utilities have floated around for years in the Access community (such as Stephan Laban's pdf merge), that library only works for Access x32 bits. With office installs now defaulting to x64 bits, then that library does not work.
So, how about writing the PDF merge code in .net?
And with .net, then that code can run as x32 bits, or x64 bits and work with both versions of Access.
And oh, just wow, google PDF merging in .net, and you get 100's and 100's of options and examples!!! So, once again, being able to leverage the .net eco system in VBA provides huge benefits. And the other bonus is that .net code can be used by Access x32, or Access x64 bit version!
So, you can find my free PDF merge files for Access written in .net here:
[http://www.kallal.ca/Articles/Pdf/Merge.html]
So, for above, I used PDFSharp, and now I have a easy to use pdf merge from my VBA code. (and is while we are at this? Is not NuGet in VS one of the most amazing features of VS?). So, this sharing, and super ease of pulling new code libraries into VS is among top reason for using VS.
In other words, not much benefits from trying to edit VBA code in VS. You only gain a text editor, and one without any syntax error checking, or autocomplete while you code.
So, I tend to flip the approach around.
The goal THEN becomes this:
How can I easy, and I mean REALLY easy consume and use .net code in ms-access?
How can I do this without having to register .dll’s, and doing all kinds of setup or isntqller code to register the .net code to be used from Access?
Well, the answer is you don’t have to do anything more then just drop the .net .dll in the same location as the Access front end. Use my provided .net class “side loader” in the above example. This will allow you with ZERO installing, and ZERO registering of .net .dll's to be called from and used from Access.
So, don’t try to consume or edit VBA code in Visual Studio (VS), but go the other direction.
(consume + use .net code in VBA).
Thus, you gain near unlimited abilities in your Access applications.