New maintainers and new versions of VBA Sync
chelh opened this issue · 9 comments
VBA Sync is now public domain software. Any new authors please use this thread to advertise your version.
To build the project, you will need Visual Studio 2017 or later. Also download VBACompressionCodec.dll to the src directory.
Hi, It looks like I'm about to start a fairly large VBA project and I've been looking at ways of putting VBA under source control. I am pleased to have found your repository and your tools looks excellent. If I do get involved in the VBA project then I also be interested in maintaining the project. I should be able to let you know in the next 3 - 4 weeks.
Martin
I’ve decided when I release v2.2.0, I’ll most likely put my own portion of the project into the public domain. Thereafter anyone will be able to release their own version of VBA Sync. No need to rename the project, credit me, or include the original license terms – though all these things would definitely be appreciated!
If you do decide to start up your own version of VBA Sync, please link it here so others may find it.
I’ll leave my own repository page as-is so that the last version of the original work is preserved.
Hi Chelsea,
I can see that a lot of effort went into your project. Very impressive!
I have been trying to run the project from the source code. It compiles just fine, but it will not run. I am using VS 2017 and this is the line that fails:
Assembly.Load("VBASync.WPF")
.GetType("VBASync.WPF.WpfManager")
.GetMethod("RunWpf", BindingFlags.Public | BindingFlags.Static)
.Invoke(null, new object[] { startup, !File.Exists(lastSessionPath) });
Any idea why that may be?
If I load the dll with AssemblyLoadFrom it will run, but then it does not work right. The executable that I downloaded works perfectly.
I would very much appreciate any suggestions on how to fix that.
@Rudiboy
maybe this should be in a new issue.
I just tried it for the first time myself.
Basically VBA.Sync is build into VBASync/bin/Debug
VBASyncWPF is build into VBASyncWpf/bin/Debug but copies the reference to VBA.Sync into the output.
Therefore if you start VBA.Sync directly (which VS Debugger would do) it won't find VBA.Sync.Wpf)
Easy fix would change the output paths of both projects to build in the same folder(s)(release/debug)
I just hardcoded in my VS that VBA.Sync ouputs to $YourFolderpath\VBASync-2.2.0\VBASync-2.2.0\src\VBASync.WPF\bin\Debug\
@SiNeumann,
Thanks for sharing. I did not think of that. It works fine after changing the output path.
@SiNeumann @Rudiboy @MartinDavidWaller - hi guys, just checking what the status of this repository is? are you guys maintaining this in any way? and whats your main use case for VBA sync? reason I'm asking is that we maintain a GH repo that does something similar-ish but for Git only (https://github.com/ZoomerAnalytics/git-xltrail) so I'm trying to find out what the common use case is. thanks!
I encountered a bug using Excel files saved in Office 2019 Pro.
When trying to extract, a pop-up message is displayed that says: "Unknown record id '0x004A'."
Excel 2019 Pro includes a new PROJECTCOMPATVERSION Record (section 2.3.4.2.1.2) with Id 0x004A.
Specification used (retrieved on 17 August 2021):
https://interoperability.blob.core.windows.net/files/MS-OVBA/%5bMS-OVBA%5d.pdf
To fix the bug, I added the PROJECTCOMPATVERSION Record to the list of ignored records in src/VBASync/Model/VbaTemporaryFolder.cs with 8 bytes of information.
I also had to add EPPlus package needed for "using OfficeOpenXml.Utils"
NOTE: There is now a new bug. When starting VBA Sync without the -r argument, the following error is displayed before VBA Sync exists: "Cannot load WPF UI. If your system is non-Windows or otherwise doesn't support WPF, you may only run VBA Sync Tool by specifying -r on the command-line."
The work-around is to run VBA Sync from the command-line with the -r argument.
My fix commit can be found @ jbviviers/VBASync@b58410b
@jbviviers I have the same problem. Could you provide a package for your improvement?