Binary locations misunderstood (winVS2017)

Come on man! If I want to compile to win32 the projucer should change the location, we’ve already established that %ProgramW6432% is always expanded to the same place no matter what VS is set to - ALWAYS.
My point is, why provide a choice in the first place if it’s going to break functionality?

If you want to build 32-bit and 64-bit versions of your plugin then you should have different build configurations for each in the Projucer:

This way you can have different copy locations set for each build and you won’t need to add a new configuration in VS whenever you re-save the project. It would be a bad idea for the Projucer to mess around with replacing Windows environment variables like you suggested as these are expected to be preserved and expanded in VS.

1 Like

Adding another configuration is an interesting work-around, thanks. A bit overblown possibly. Now that I’ve had my usual lovely walk in the sunshine for an hour, I’ll probably just fix the Projucer myself - it’s just the copy call in the Post-build after all. That way I can put 32 & 64 builds in the correct place with a simple exporter for Debug & Release. I’ll probably change the variable to ‘(Architecture)/vstplugins’ or something obvious.
No problem, I’ll probably enjoy it. Something to do while I’m waiting for my iLok3 to arrive…

i’m getting an error on my end related to this:

The command "copy /Y "C:\...\Builds\VisualStudio2017\x64\Debug\VST3\test.vst3" "%CommonProgramW6432%\VST3\test.vst3"
:VCEnd" exited with code 1.	

I’m on a Parallels install of windows 10 with no DAWs installed so maybe that’s part of the problem? it seems like Visual Studio isn’t expanding that environment variable correctly, even though I see it set properly in Command Prompt.

C:\Users\matka>echo %CommonProgramW6432%
C:\Program Files\Common Files

I’ve pulled the latest tip from the Develop branch, rebuilt projucer, and still see this in Visual Studio:

so, for some reason, the %CommonProgramW3264 isn’t being wrapped in $()

AFAIK this variable is not defined by the build system but from cmd.exe, hence no wrapping in $().

I’d rather think your second conclusion is the key: since no DAW is installed, the VST3 path doesn’t exist, and copy will not create the directory.
Can you try creating the directory manually?
And if that helps, maybe the copy command should be amended with a md /y %CommonProgramW6432%\VST3?

no, the folder exists. When I check its properties, it’s “read-only”.

When I turn on Diagnostic debug output, i get a Access Is Denied error on that copy step.

Sounds like you found it?
Does it work then, if you turn off read only?

I am having the same issue as @matkatmusic, with VST builds not able to be copied to the VST3 folder, because of “Access denied”/“exited with code 1” errors.

I also see the same thing when I view Properties for C:\Program Files\Common Files\VST3, that it is marked as “Read-only”.

Unfortunately not. Although the Properties window allows you to uncheck the “Read-only” box, and doesn’t complain when you click the “Apply” or “OK” buttons, it doesn’t seem to actually DO anything. When I re-open the Properties window after clicking OK, the Read-only box is once again checked.


There are possibly some helpful ideas here:

In short, the real fix involves diving into the “Security” tab of the Properties window, and changing something there. I modified the “Users” Group to have Write permissions, and that fixed the VST3 build copy errors for me:

Frustratingly, even though my Windows 10 user account is set up as an “Administrator”, and the “Administrators” group already had Write permission for the VST3 folder, somehow under the logic of Windows that still didn’t permit me to write to that folder. It is those sorts of ill-conceived and poorly communicated system design decisions that have made me swear more than once that I was simply going to drop supporting Windows altogether.

Dropping support becuase you don’t understand something? Always a good idea - sounds like me and Macs! Bloody computers. :slight_smile:
TBH we’ve all managed to get VS to write to those directories. Mine says it’s read only as well, but I’ve got permissions for ‘Everyone’ and ‘Administrators’ if that helps at all?

  • Note: ‘Full control’ enabled

Ah, well, if it was just ONE thing, then that would be no big deal. But when every interaction is complicated by counter-intuitive design decisions, it makes me dread even stepping into the Windows zone of suck.

(Why, for example, can I still not in Windows 10 select text from error messages and copy it with a simple ctrl+C shortcut? So when I get inscrutable error messages, not only do I have to stop and Google for their meaning, but I have to transcribe the damn thing off the screen? There are many many more examples of Windows systemic suckitude I could list, but I know this isn’t the place and that they aren’t personally your fault, @DaveH… so I won’t subject you to them.)

In this case of changing the VST3 folder permissions, it did work for me to change the “Users” group to have write permissions… and yes, it does still say (incorrectly) that it has “Read-only” as an attribute.

? Copy/Paste errors works fine for me:-

e:\plug-ins\quikquak_juce\mashtactic\source\plugineditor.cpp(301): error C2143: syntax error: missing ';' before 'constant'

The issue you are facing is not due to the folder being read-only. From :

Note Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.

You are making an attribution error here. Yes, you are an Administrator, and yes, Administrators have write access to that folder. But you are not running the script that fails to write to that folder, Visual Studio is.

You have to make sure that Visual Studio runs as Administrator.

1 Like

Errors from the Visual Studio Error List copy fine - I’m talking about system error messages like:

Where the text isn’t selectable as text, and ctrl+C doesn’t copy the text.

That error is pretty self explanatory, to be fair. Granted, some are a bit more cryptic.

Thanks for explaining, but that still seems counter-intuitive to me. I’m the user, and processes that I start should run under my permissions. The idea that I would have to go to the Properties dialog for an app’s shortcut (not even the Properties for the app itself) to tell the app to “Run as administrator” is bizarre to me. Feels very kludgy.

Dude, there are a million things Windows users find shitty and strange on the OSX/Linux side of things, but they are less self-righteous about it here. It’s natural to be confused by unfamiliar things, but this sort of generalization and demonization is not helpful.

En contraire. From a safety perspective it would be catastrophic, if any process a user with administrative privileges would run with the highest privileges. When Windows adapted the multi user approach in Windows NT, they expected you to log out and back in as a different user. Needless to say, that people started to use administrator account only, leaving your system unprotected even for web browsers (once they were invented)

OK… so the safety measure here that you’re pointing out is that Windows doesn’t run processes “as an Administrator” by default?

However, as an Administrator I have the ability to tell any process to “Run As Administrator”. So I’m not actually blocked from running any process “with the highest privileges”… I just have to know to know one of the ways to work around it. Is that correct?

Yes, sorry, was interrupted, so the post was a bit shorter than intended.

There is one option to run VS as administrator. But AFAIK there is the other solution, to use a group for access control. I am not a regular windows user, but I know the features exist similar to the Unix world:

  • Create a group e.g. named developer
  • Add yourself to the group
  • grant full access for the group developer to write to the folder in question

This way you only give as much privilege as you have to to fulfil the task of copying.

Maybe this how-to guide helps

Fun fact: developing on windows was long time problematic, and in many instances only possible by running VS as administrator. They adapted more and more developer demands, to make developing possible. They were probably just not aware enough of audio plugin developers, so a bit of tweaking is still necessary.