Can the VCS be run as a standalone program (Not Add-in)?

[AzuresSkye]

My organization is really tight on security. Everytime I run the VCS, I get an "The wizard you've requested is not installed or is in a bad state." error. I've tried installing it without the Ribbon, as an ACCDE, and even with the location Trusted. Looking through my security settings, I can't use COM Add-Ins or Trust Locations. There's been talk of disabling Trusted Documents, even. 😥

Is there any way to use this as a standalone program, instead of as an Access Add-in?

[joyfullservice]

To directly answer your question, no, this is only designed to run as an add-in. For some very basic functionality, you could look at the original project this add-in was inspired from, msaccess-vcs-integration/msaccess-vcs-integration, however this legacy project has had few updates and lacks much of the functionality of this add-in.

I am sorry to hear of the challenges with security. It can be a difficult balance between maintaining a secure environment while still giving people the tools to get their job done. You may have already seen this, but I have put together a Security Considerations page that outlines what this add-in requires and why. This could be a good starting point for a discussion with your supervisor and/or security team to understand your needs.

I recognize that from the perspective of those responsible for security, they would prefer to keep things just as secure as possible. I understand that, and that this is their responsibility and focus. But the balance to this is that people need to perform their job functions effectively to ultimately be successful in the overall mission of the organization. If they are open to a broader perspective, here are a few points that could be helpful in the discussion.

• Frequently exporting the source code of the applications you are developing and maintaining this in version control actually enhances security! Just like they maintain logs of activity and security events, this allows you to maintain a log of changes to software. If malicious code or an inadvertent back door was discovered, you could trace it back to exactly when it was introduced, and have a much better understanding of what happened.
• The add-in itself is open source, meaning that every line of source code can be inspected and analyzed by anyone. This makes the add-in more secure because risks can be identified and mitigated by many developers with varied backgrounds and experience. (As compared to closed-source software that was only reviewed by a single developer or small team.) Not to mention that in closed source solutions, you really don't fully know what is happening inside the black box of the compiled software.)
• The ultimate mission of your organization is furthered by internal efficiency of your development workflow. Confidence to deploy faster updates at lower cost is one of the real benefits of using this add-in with Microsoft Access development.
• Some people have been successful in getting their organization to approve the trusting of the add-in location (i.e. %AppData%\MSAccessVCS. Note that this does not trust all add-ins, but just this add-in's unique installation folder. (That's why we install the add-in in a dedicated folder, not the default add-in install location.)

Ultimately your organization is going to have to decide what is more important to them. It is "more secure" to not use computers at all, and not have any people at the office, but it's kind of hard to get much done that way. 😁 Hopefully you can have some profitable discussions with some of the leadership and effectively communicate how the benefits of the tool outweigh the perceived risks. (In reality, if you are developing and using Microsoft Access applications, almost all of those risks are already there.)

I have tried to do what I can to keep those risks as low as possible, but let me know if you have additional input on how we can make this tool more available to developers working in secured environments.

[josef-poetzl]

You could try whether you can start the add-in from the application folder.

1. Copy version Control.accda to the application directory.
2. Start the add-in directly from the application: Application.Run CurrentProject.Path & "\Version Control.AddInMenuItemLaunch"

[AzuresSkye]

That absolutely worked. A little clunky, but it got the job done! Thank you :)

[joyfullservice]

Glad to hear that worked! Technically, the add-in should be able to run from any location as long as the file or location is trusted. That might save you from having to put copies of the add-in in every project you are working on. 😄 You may even be able to run it from the default install folder, as long as you are able to trust the file. @hecon5 describes that in more detail below.

If the ribbon is a no-go, (at least initially), you may be able to come up with a less clunky way to launch it. For example, you might be able to add a shortcut to the quick launch bar that runs a specific function or macro to launch the add-in.

[hecon5]

Fellow Very Securious Org member here.

We have had to work with our IT / OT groups to allow us to use this addon, in fact, so much so that they made us install it into a separate location even from the addin's normal spot.

We've also experienced the issues you mentioned.

A few tips that have helped us:

1. Be persistent. We had to bug our IT groups for a while to get permissions.
2. Ensure "Open Addin After Install" is selected.
3. Ensure "Trust Add-In Folder" is selected.
4. Try installing with the ribbon.
5. Ensure Access is allowed to run macros.

For some users, even opening the add-in after install didn't work. In this case, we did the following:

1. In the VBAIDE, add the addin as a reference.
2. Go to Tools > References > Browse.
3. Browse to the addin's installed location.
4. Select "All Files" (otherwise only .dlls and other typical reference files show up).
5. Select the Version Control.accda file.
6. Make sure it's checked.
7. It should show up on the left hand object browser.
8. Now try running the addin again.

Access finally has the ability to sign the VBA environment, so you should be able to sign your code environment with a code signing certificate; this has the added benefit of increasing trust in your org. You will either need to get a code signing cert from your org or make your own.