RegAsm? Did I miss something? Up until now we were discussing RegSvr32 to register the COM server.
By default RegSvr32 will only register the library at system level (DllRegisterServer) which requires admin permissions. However, if your DLL supports user level installation in its DllInstall function, it can be registered with RegSvr32 by passing the appropriate command line switch.
Independently of RegSvr32 (and RegAsm), you can also write the required Registry settings for the DLL using either a .reg file, a batch script or even VBA. This definitely works without admin permissions when just writing to HKCU for the current user.
Yes, of course, for native COM libraries, those written in C++, regsvr32.exe is fine
I wrote regasm.exe because in my case, they are libraries created as dot-net assemblies, with c# language
This is of fundamental importance. You should have included this information in your very first post because people gave you a lot of very good advice which, as it turns out only now, is not really applicable in your case.
This is of fundamental importance. You should have included this information in your very first post because people gave you a lot of very good advice which, as it turns out only now, is not really applicable in your case.
My confusion remains. In order to have the file be usable, if YOU created it, how do you not know where it is and what it is? This library didn't get to a usable location via telepathy or time-travel. Someone put it somewhere and, since you created it, how is that someone not you?
My confusion remains. In order to have the file be usable, if YOU created it, how do you not know where it is and what it is? This library didn't get to a usable location via telepathy or time-travel. Someone put it somewhere and, since you created it, how is that someone not you?
The PEPPE.ACCDE program was initially created without the use of external libraries
In later versions, the PEPPE.ACCDE program began using external libraries
A user attempting to use the latest versions of PEPPE.ACCDE without placing the external libraries in the correct location and registering them so the operating system knows about them would be unable to run the program correctly
And the code couldn't provide any useful information other than the fact that something is missing
But what is missing? The code doesn't know
At least until it is provided with a correspondence between the GUID and the library
This last thing, although simple, was missing
I have an Access procedure that searches for newer versions upon startup
If available, downloads them to the root program directory and creates a new icon on the desktop to launch them
Sometimes, newer versions require an additional library in the references; otherwise, the code won't work correctly
The question is: how can I verify that all the required libraries are loaded, and if not, how can I start the library registration process (using VBA code, I mean)?
Ok, keep in mind there are 3 types of .dll’s that are “common” used with Access.
First type: - windows .dll with entry points
A standard windows .dll, one with entry points. These are the ones that you use VBA declare statements.
Such as this one:
Code:
Private Declare PtrSafe Function MyCreateObject Lib "nloader.dll" _
(ByVal strDll As String, ByVal strClass As String) As Object
The above .dll’s are NOT class objects, and do NOT require a regsvr32.exe. And they do NOT require VBA CreateObject.
Second Type: Windows COM objects.
Then we have registered windows “COM” objects. These work much the same when you create an instance of Outlook or Word, or whatever. You thus use VBA CreateObject() in VBA.
Keep in mind, that when using regsve32.exe, there are 2 versions installed on windows
One for x64 bit applications
One for x32 bit applications.
So, depending on which version of Access (x32 or x64), you have to use the correct version of regsvr32.exe.
Third type: .net framework .dll objects - seen in VBA as windows COM objects.
The next type of dll, (and what I tend to use now), are so called .net .dll’s. Such .dll’s require use of the .net regams.exe in place of regsvr32.exe.
What regams.exe does is creates/installs the.net .dll as a windows standard registered COM object. And again, there is a x64 bit version, and a x32 bit version of regasm.exe.
However, I have found more and more installation sites have more and more locked down computers. This means that attempts to register a .dll tends to require elevated rights.
As a result, I now use a “side load” approach, and thus don’t have to register my .net .dll’s with regasm.exe. This allows so called x-copy deployments (you only need to copy the access front end, and some .dll’s into the same folder – and everything just works! So, this is COM free .net registration, and it saves me boatloads of hassles.
So, both regsver32, and regams (for .net .dll’s) tends these days to required elevated rights.
And if you are IN LUCK?
If you only are using regasm (.net .dlls), then I suggest you grab a copy of my VBA .net loader – it will load the .dll’s for you, and do so without requiring regasm. Just place the .dll in the same location as the access front end, and you good to go.
I have a .net .dll that does PDF mering from VBA -- and thus you can try my sample Access PDF merge here:
Link:
[link not allowed]
The above includes a access form that looks like this:
(do keep in mind that when you download the .zip file, make sure to un-block the downloaded file before un-zipping. However, I assume all developers do this by habit anyway (unblock).
Speaking of hassles? Before I adopted the .net side loading approach from VBA? I still STRONG recommend that you adopt a installer.
That installer can:
Check for Access, or Access runtime – it not present, then install it.
Check for and register your required .dll’s .
Check for things like say a custom bar code font, and again, if missing, then install the font.
Place a shortcut on the desktop.
Check if your trying to install to a computer running terminal services, and thus change/use a different location then say C: drive.
So, all of these “common” install issues? Including building a automatic front end updater? They can all with ease be “solved” by adopting a installer.
And with just a few lines of VBA code, you can leverage the installer to also “auto update” your front end with great ease…
There are a number of free installers one can use – I’ve been using Inno installer for years but really, the point here is to adopt “some” kind of installer, since they tend to have options to register .dlls, and even .net ones. And you can detect if office is a x64 bit install, or a x32 one….
Edit: seems I can't post links - perhaps I'm new here (no worries).
Hi Albert, just a quick heads up, due to this site's propensity to attract spammers, you will need to have around 100 posts before you will be able to post links.
d
Ok, keep in mind there are 3 types of .dll’s that are “common” used with Access.
First type: - windows .dll with entry points
A standard windows .dll, one with entry points. These are the ones that you use VBA declare statements.
Such as this one:
Code:
Private Declare PtrSafe Function MyCreateObject Lib "nloader.dll" _
(ByVal strDll As String, ByVal strClass As String) As Object
The above .dll’s are NOT class objects, and do NOT require a regsvr32.exe. And they do NOT require VBA CreateObject.
Second Type: Windows COM objects.
Then we have registered windows “COM” objects. These work much the same when you create an instance of Outlook or Word, or whatever. You thus use VBA CreateObject() in VBA.
Keep in mind, that when using regsve32.exe, there are 2 versions installed on windows
One for x64 bit applications
One for x32 bit applications.
So, depending on which version of Access (x32 or x64), you have to use the correct version of regsvr32.exe.
Third type: .net framework .dll objects - seen in VBA as windows COM objects.
The next type of dll, (and what I tend to use now), are so called .net .dll’s. Such .dll’s require use of the .net regams.exe in place of regsvr32.exe.
What regams.exe does is creates/installs the.net .dll as a windows standard registered COM object. And again, there is a x64 bit version, and a x32 bit version of regasm.exe.
However, I have found more and more installation sites have more and more locked down computers. This means that attempts to register a .dll tends to require elevated rights.
As a result, I now use a “side load” approach, and thus don’t have to register my .net .dll’s with regasm.exe. This allows so called x-copy deployments (you only need to copy the access front end, and some .dll’s into the same folder – and everything just works! So, this is COM free .net registration, and it saves me boatloads of hassles.
So, both regsver32, and regams (for .net .dll’s) tends these days to required elevated rights.
And if you are IN LUCK?
If you only are using regasm (.net .dlls), then I suggest you grab a copy of my VBA .net loader – it will load the .dll’s for you, and do so without requiring regasm. Just place the .dll in the same location as the access front end, and you good to go.
I have a .net .dll that does PDF mering from VBA -- and thus you can try my sample Access PDF merge here:
(do keep in mind that when you download the .zip file, make sure to un-block the downloaded file before un-zipping. However, I assume all developers do this by habit anyway (unblock).
Speaking of hassles? Before I adopted the .net side loading approach from VBA? I still STRONG recommend that you adopt a installer.
That installer can:
Check for Access, or Access runtime – it not present, then install it.
Check for and register your required .dll’s .
Check for things like say a custom bar code font, and again, if missing, then install the font.
Place a shortcut on the desktop.
Check if your trying to install to a computer running terminal services, and thus change/use a different location then say C: drive.
So, all of these “common” install issues? Including building a automatic front end updater? They can all with ease be “solved” by adopting a installer.
And with just a few lines of VBA code, you can leverage the installer to also “auto update” your front end with great ease…
There are a number of free installers one can use – I’ve been using Inno installer for years but really, the point here is to adopt “some” kind of installer, since they tend to have options to register .dlls, and even .net ones. And you can detect if office is a x64 bit install, or a x32 one….
Edit: seems I can't post links - perhaps I'm new here (no worries).
Ok, keep in mind there are 3 types of .dll’s that are “common” used with Access.
First type: - windows .dll with entry points
A standard windows .dll, one with entry points. These are the ones that you use VBA declare statements.
Such as this one:
Code:
Private Declare PtrSafe Function MyCreateObject Lib "nloader.dll" _
(ByVal strDll As String, ByVal strClass As String) As Object
The above .dll’s are NOT class objects, and do NOT require a regsvr32.exe. And they do NOT require VBA CreateObject.
Second Type: Windows COM objects.
Then we have registered windows “COM” objects. These work much the same when you create an instance of Outlook or Word, or whatever. You thus use VBA CreateObject() in VBA.
Keep in mind, that when using regsve32.exe, there are 2 versions installed on windows
One for x64 bit applications
One for x32 bit applications.
So, depending on which version of Access (x32 or x64), you have to use the correct version of regsvr32.exe.
Third type: .net framework .dll objects - seen in VBA as windows COM objects.
The next type of dll, (and what I tend to use now), are so called .net .dll’s. Such .dll’s require use of the .net regams.exe in place of regsvr32.exe.
What regams.exe does is creates/installs the.net .dll as a windows standard registered COM object. And again, there is a x64 bit version, and a x32 bit version of regasm.exe.
However, I have found more and more installation sites have more and more locked down computers. This means that attempts to register a .dll tends to require elevated rights.
As a result, I now use a “side load” approach, and thus don’t have to register my .net .dll’s with regasm.exe. This allows so called x-copy deployments (you only need to copy the access front end, and some .dll’s into the same folder – and everything just works! So, this is COM free .net registration, and it saves me boatloads of hassles.
So, both regsver32, and regams (for .net .dll’s) tends these days to required elevated rights.
And if you are IN LUCK?
If you only are using regasm (.net .dlls), then I suggest you grab a copy of my VBA .net loader – it will load the .dll’s for you, and do so without requiring regasm. Just place the .dll in the same location as the access front end, and you good to go.
I have a .net .dll that does PDF mering from VBA -- and thus you can try my sample Access PDF merge here:
(do keep in mind that when you download the .zip file, make sure to un-block the downloaded file before un-zipping. However, I assume all developers do this by habit anyway (unblock).
Speaking of hassles? Before I adopted the .net side loading approach from VBA? I still STRONG recommend that you adopt a installer.
That installer can:
Check for Access, or Access runtime – it not present, then install it.
Check for and register your required .dll’s .
Check for things like say a custom bar code font, and again, if missing, then install the font.
Place a shortcut on the desktop.
Check if your trying to install to a computer running terminal services, and thus change/use a different location then say C: drive.
So, all of these “common” install issues? Including building a automatic front end updater? They can all with ease be “solved” by adopting a installer.
And with just a few lines of VBA code, you can leverage the installer to also “auto update” your front end with great ease…
There are a number of free installers one can use – I’ve been using Inno installer for years but really, the point here is to adopt “some” kind of installer, since they tend to have options to register .dlls, and even .net ones. And you can detect if office is a x64 bit install, or a x32 one….
Edit: seems I can't post links - perhaps I'm new here (no worries).
regasm is what I've been using to register custom assemblies for my Access/DotNet interop apps that interface with online services. It's important to prioritise your references in proper order. I don't think it's a good idea to do all these steps with vba.
Code:
Option Explicit
Option Compare Database
#If VBA7 Then ' Access 2010 or later
Public Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal Milliseconds As LongPtr)
#Else ' Access 2007 or earlier
Public Declare Sub Sleep Lib "kernel32" (ByVal Milliseconds As Long)
#End If
Public Function QBOTest()
' Our .NET interface
Dim qbo As QBOInterface.QBOInterface
Set qbo = New QBOInterface.QBOInterface
Dim authCode As String, realmID As String
' Authorization Code, one-time code from QBO that authorizes our application to read data from customer's QBO account
authCode = DLookup("AuthCode", "QBOAuthentication") ' will need to be entered by the user
' Unique identifier for the client's company in QBO
realmID = DLookup("RealmID", "QBOAuthentication")
' Init: clientID, clientSecret, redirectURL, environment, authCode, realmID
' These must match exactly what the web application uses
' ClientID and ClientSecret come from QBO Developer Account portal
qbo.Init "Q0uEmaJmYxjLE73PffMaG0EhIhG7**************", "WyBAFRAoLjGwXF27zjl2OUnBjwA**************", "https://accessqbotest.azurewebsites.net/callback", "sandbox", authCode, realmID
Dim aToken As String, rToken As String
' Access Token, used to communicate with the QBO API, expires within 60 minutes
aToken = "" ' will come from the database, otherwise will be blank
' Refresh Token, used to request Access Tokens, expires after 100 days
rToken = DLookup("RefreshToken", "QBOAuthentication") ' will come from the database, if QBO connectivity has occurred before, otherwise this will be blank
' Gets our Access Token, if we don't already have one to use
qbo.GetToken aToken, rToken
Sleep 2000 ' Short delay is required for the API to be called and response received/processed
' MsgBox "Access Token: " & qbo.AccessToken
' MsgBox "Refresh Token: " & qbo.refreshToken
Dim companyInfo As String
companyInfo = qbo.GetCompanyInfo
' MsgBox "Company Info (JSON): " & companyInfo
Dim Json As Object
Set Json = JsonConverter.ParseJson(companyInfo)
Dim sql As String
Dim dbs As DAO.Database
Set dbs = CurrentDb()
RunSQL "DELETE FROM QBOCompany", dbs
RunSQL "INSERT INTO QBOCompany (ID, CompanyName, CompanyAddr_City, CompanyAddr_Country, CompanyAddr_Line1, CompanyAddr_PostalCode, PrimaryPhone, EmailAddress) VALUES ('" & Json("Id") & "', '" & Json("CompanyName") & "', '" & Json("CompanyAddr")("City") & "', '" & Json("CompanyAddr")("Country") & "', '" & Json("CompanyAddr")("Line1") & "', '" & Json("CompanyAddr")("PostalCode") & "', '" & Json("PrimaryPhone")("FreeFormNumber") & "', '" & Json("Email")("Address") & "')", dbs
dbs.Close
Set dbs = Nothing
MsgBox "Sync complete!"
End Function
Private Sub RunSQL(sql As String, dbs As DAO.Database)
dbs.Execute sql, dbFailOnError
End Sub
Hi Albert, just a quick heads up, due to this site's propensity to attract spammers, you will need to have around 100 posts before you will be able to post links.
d
Good to see you posting here Albert and hadn't realised you had in fact been a member since 2009.
I've just spent half an hour reading all your old posts to this forum, full of wisdom and, of course, written in your own unique and entertaining style.
So although you certainly aren't new here, a huge welcome to the forum
Welcome back! We missed your expertise and much needed humor. A lot has been going on recently in AWF.
Albert's posts from year 2015 have embedded links, so can he now be grandfathered in for posting links even though he has not reached the 100 posts threshold?
