@RubberDuck the target's ComponentName is the name of the module - in that case a UserForm, so that's renaming ControlButton1_Click to MyForm_TheNewName
you need to replace the _view.Target.IdentifierName + '_' in the signature with _view.NewName + '_'
public override void Run(string projectName, string moduleName, string methodName)
{
//Outlook does not support the run method.
throw new NotImplementedException("Unit Testing not supported for Outlook");
}
> System.Reflection.TargetInvocationException was unhandled Message: An unhandled exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll Additional information: Exception has been thrown by the target of an invocation.
> But if you have an assembly marked with vsdraCOM for registration the resulting component does NOT have the 64-bit setting (the msidbComponentAttributes64bit is not set) so you get registration in the 32-bit registry.
If you guys are really hating the installer then you could consider using Inno Script instead. The upside is that everything is in a single text file and can be chained into the post build event for VS. I know I've suggested this before.
Unfortunately, I've lost access to a script that would have been very useful to you.
I ran into this issue not long ago. The short answer is that if you run a 32 bit application on a 64 bit machine then it's registry keys are located under a Wow6432Node.
For example, let's say you have an application that stores its registry information under:
HKEY_LOCAL_MACHINE\SOFTWARE\Compa...
@Mat'sMug Could we change it so it could register in either?
IDK.. right now it's not registering anywhere for me
A 32 bit binary will work on both platforms, but if you specifically want to offer a 64 bit version of your binary then yes, you need to build one for each platform. — 17 of 26May 17 '09 at 16:33
I saw in the documentation that you need to create the directory %appdata%\Rubberduck. Does the installer create that? Why can't RD create that directory by itself like other apps normally do?
I added regasm.exe $(targetpath) /unregister to prebuild, and regasm.exe $(targetpath) /codebase to postbuild - the postbuild is somehow not working, but if I run it manually then RD loads in Excel, which is a good sign - I'm about to get my debug build fixed.
done
I have a working debug build that launches Excel from VS with the process attached!
at fucking last
and the key to not creating hundreds of registry keys, is the prebuild /unregister step.
since the x86 / 32-bit debug build seems to "just work", I only added these steps to the debug64 config.
committing.
pushed to master.
oooookay ...now VBE/Excel just closes (crashes) on load when it's parsing code. I'm annoyed.
confirmed - it's the Code Explorer crashing it.
that doesn't make any sense
no, it's not the Code Explorer
wtf
"Excel has stopped working"
ah
well look at that
component.Name is null
oh it's a msForm
@RubberDuck and now I got a repro on the System.Reflection exception you had earlier. But it's an AccessViolation that's shutting down Excel
and we're not catching the AccessViolationException:
I'll look at that tomorrow. Committing for now, I've fixed the rename bug for form controls
fizzbuzz.xlsm loads fine
I bet it has to do with forms
don't ask why
way past TTGTB here.
Anyway Chris when you read this you can pull master knowing the rename bug is fixed, so if you manage to figure out that access violation you should be good to go with a 3.01 x86 release
I am currently working with the explicit finite difference method and I have a code for this method. The code is written in VBA and now our teacher wants us to write the code so that we can use it in R. I am new to programming so I have a couple of problems.
In the VBA code they use the functio...
@RubberDuck I'm working on this script and I want to make a single installer to install both versions - since they are both compiled as AnyCPU. Just the registration differs. So I want to determine the bitness of Office. Is it possible that someone can have two different bitnesses of Office on the same machine? Do we want to let the user override the chosen bitness (radio button)? Other questions go here.
So does LibGit2Sharp.dll change with the bitness of the compilation or is it compiled as AnyCPU too? Or is it that the installer needs to copy the correct version of git2-exxxxx.dll to the parent folder for debugging from VS? Because I'm not too concerned with the latter right now.
I can make the installer choose one of the git2-exxxxx.dll files to copy to the installation dir (I obviously can't do both).
@Mat'sMug I'm out of time here, but if with the "register for com interop" button on the "Build" property page unchecked, it runs for me, but (obviously) doesn't register the newest version of the assembly.
If I check it, I get the crazy reflection error when I try to debug.
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]