I'm working on making slight changes to a legacy VS 2008 & MFC project, including changes to the WinAPI/MFC *.rc resource file. I have made those changes, e.g., changing a menu string (for IDR_MAINFRAME, if it matters) from "New Scan" to "New Organism" on one computer, commited to VCS, and tried rebuilding the project on another, practically identical configuration (not sure if relevant), which is when I ran into problems.
Currently, I have
changes to the menu from within the VS resource editor that do not propagate into the application (old values remain)
changes to the about dialog that do propagate into the application
an RC file that contains no mention of "New Scan"
no file, including binaries, containing "New Scan" (though, as mentioned, this might be due to encoding)
I have
cleaned and rebuilt
manually cleaned and rebuilt
deleted the *.res file and compiled just the *.rc file into a *.res just to make sure the paths there are alright
modified the configuration so that (Project -> Properties -> Resources -> Command Line) has an absolute path to the *.res file.
verified that the current module is indeed the exe being executed via GetModuleHandle
verified that all calls to FindResource and LoadResource pass NULL as the current module, meaning the resource should be loaded from the exe
verified using ResEdit that the resource within the exe contains "New Organism", even though it shows "New Scan" when run. I verified the #define for the resource is the same number as the number reported by ResEdit. Verified there's no other similar resources in the exe.
verified that I'm running the same exe I'm inspecting and tried running it from both the IDE and from Windows Explorer.
inspected all (two) non-system DLLs that get loaded (as reported by the output window and dependency walker) using ResEdit and both of them belong to a 3rd paty library and none of them contain any menu resources (they only contain manifests).
tried changing/removing the command that loads the menu (CFrameWndEx::LoadFrame) and verified it forces the application to fail.
verified that having an IDR_AppnameTYPE MENU with a second copy of the menu doesn't help (see thomiel's answer below)
Using google
To no avail. I am especially unsure where the original string, "New Scan", is coming from and how come changes to my about dialog propagate and changes to the menu don't. How do I make the changes to the menu propagate to the *.exe itself?
In case of a SDI or MDI: Not only change IDR_MAINFRAME but also IDR_??????TYPE, which is the menu displayed when you have an open document.
I have had the exact same problem. This is going to sound crazy, but if you create a SUB menu in the menu item, and then delete the APS AND RES files, and then SAVE ALL and to a REBUILD of the ENTIRE SOLUTION, you should be OK. Please contact me if you have any other questions. I'm happy to help.
It seems that MFC will cache the menu items in registry when you quit your application. To prove it you can copy your program to a new machine and runs it. If it displays the modified menu items normally, it means MFC uses cached menu items on your own machine.
You can clean the registry key to make your modifications take effects. The registry entry may locate at
HKEY_CURRENT_USER\Software\Local AppWizard-GeneratedApplications\MyMFCApplication1
-or-
HKEY_CURRENT_USER\Software\{your company}\{your project name}\Workspace
based on the MFC version.
Related
in InstallShield 2011, I cannot modify file permissions under Application Data -> Files and Folders. Whenever I right click on items, it shows grayed out menu buttons. I can't even delete existing entries.
In a bat script later in the installer, I can't copy over certain files because I don't have the right permissions so the installer fails when trying to reference files in BackupFiles. For some reason all the other files get copied over just fine; I can't modify those file's permissions either. I read online that you have to click the "Properties" button in that context menu to change permissions.
My version is InstallShield 2011 Premiere Edition Version 17.
I don't understand why this is grayed out. The source files do not have any restrictions on them so it must be the installer doing something related to permissions.
That boxy orange overlay on the folders and files indicates that these are coming from a Dynamic File Link. Because these files aren't actually added to your project, not all configuration options are available. You might have to edit the permissions on the source files (before build), or change your project to statically include all or some of these files. Given the size of that tree, changing it all to static could be a bit tedious. Changing parts of it (by editing the link exclusions) might be a good middle ground.
Or you could better determine what's going wrong and see if you can address it in the batch file. Assuming this is InstallScript (rather than InstallScript MSI), the entire setup along with any processes it launches should be elevated. So I'm having a hard time guessing what could go wrong. Perhaps a read-only flag? Perhaps use a tool like process monitor to get more information on that, and see if you can add a call to attrib -r, or cacls, or whatever.
Is there a file somewhere that I can use to do massive changes to the context menu in an easier fashion?
The GUI:
gives me no way to move a command from one menu to another, nor does it let me see what the command actually is (in order to add that same exact command to another menu), thus I don't have much to work with.
And thus I am seeking a file (or a gigantic registry key? ugh.) that I can edit somewhere else where I have more powerful tools. (my VS version is Enterprise 2017 if that matters)
You can find the defaults at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Profiles, with a general settings and some language-specific overrides. There's an additional override in IDE\VC\Profiles as well.
In my case, I wanted to move 'Start new instance" on a Project into the top-level context menu. So I:
Made a copy of CurrentSettings.vssettings
Added a new command where I wanted it (via the Tools > Customize... GUI)
Found the command I wanted to clone and moved it up one
Closed VS (it saves on exit)
Compared the two files to find the diffs (use your favorite tool.) You'll find them under Category[#name="Environment_CommandBars"]\CommandBars\UserCustomizations as add remove and modify entries
Took the Cmd attribute from the moved entry and pasted it over the added one (it was Cmd="{1496A755-94DE-11D0-8C3F-00C04FC2AAE2}:00000164" for me, to save interested parties a few steps)
Undid the move to retain only the added entry
I wasn't able to find a command entry for this anywhere in the defaults, so had to figure it out the hard way.
I am building a VS 2010 installer, and I want to copy files to app folder depending on what options I select in UI (UI is not simple, so the only option is to show custom dialogs in Install custom action).
The problem is that custom action is actually executed after files are copied already.
One possible solution I can think of is to install all these files into the app dir, and then delete some unnesessary files in custom action. But these files are "secure" in some way, so I don't want to copy them to filesystem, even for a short period of time.
Any thoughts?
If your files shouldn't ever be on the filesystem, you have a problem in the requirements. The .msi storage itself is an open format and can be read by many tools, so if someone knows the file it's possible for them to find and extract it manually.
I agree that it's better to avoid deleting the files after they've been installed for two reasons. One: it avoids wasted work, and two: it won't cause repair scenarios due to missing files that Windows Installer thinks should be present. You should probably figure out how to determine whether these files should be present at an earlier stage of the installation, and set properties that cause this to happen (disable components by condition, or change feature states).
Most controls in MSI dialogs use installer properties. For example, a checkbox may use a property named MY_CHECKBOX which is set to a value or it's empty, based on whether the checkbox is checked or not.
These properties can be used to condition files:
select your setup project in Solution Explorer
click File System Editor button from Solution Explorer top pane
select the file you want to condition
in its Properties pane set Condition field to the condition you want, for example
MY_CHECKBOX = "value"
I'm working on an XNA project and modify a graphical asset outside of Visual Studio. In order for those changes to show up in the application, I need to remove the reference to the original image, and then re-add the same image to see the changes. This happens whether I do a complete rebuild or not. Is there a way to streamline this process so that my project shows the changes I've made without having to remove the content reference and then re-adding it after each change.
XNA is pretty smart, and only wants to re-run assets through the content pipeline when it detects something has changed. For some reason it isn't seeing the changes you are making.
Make sure you are modifying the correct file. For example if your original image is at c:\myImage.png and your project is as c:\myGame when you add the image to the Content Project it gets copied to c:\myGame\myGameContent. Editing the image at c:\myImage.png wont get noticed. You need to edit c:\myGame\myGameContent\myImage.png
If you are editing the correct file and it still won't update, try touching another file. As smart as the engine is, it will run everything through the Content Pipeline when it detects 1 item has changed.* If that still doesn't work If you look at the top of the Solution Explorer there is a refresh button. Try pressing it as it should make sure your Solution Tree is in sync with the files on disk.
*note this is true for v3.1 it could have changed for 4.0
When you drag an item into a Visual Studio project (like, in this case, a Content Project), it will copy the file into the project directory. By default it does not reference the file you drag in (although that is available as an option).
(If the file you drag in is already in the project directory, it just leaves it there.)
The upshot of this is that you need to work on your content files in the content project directory, if you want to see your updates happen immediately.
If you don't know where the files are being copied to, select one of them in your content project and press F4 (properties window). Find the "Full Path" entry. That is where your files are stored.
I am currently bug hunting and need to debug into a specific dll in the release configuration in Visual Studio 2005.
At some point I closed the solution, did some other stuff and reloaded it. From that point on my breakpoint doesn't get hit and I get the infamous "No symbols have been loaded..." message. So I opened the modules window and the dll that I want to debug doesn't appear in the list anymore, therefore I cannot load symbols manually. The application behaves normal so I am absolutely sure that the dll MUST have been loaded to execute certain functions. Sure enough, if I rename the dll and start up the application it doesn't work anymore, so it also must be the right dll.
I tried setting the dll project as startup project and the command to execute to the application's exe and starting the application from outside visual studio and then attaching to the process, all to no avail.
Question is, why is the dll not appearing in the list of loaded modules although it must have been loaded? I cannot think of any other changes that I've done, that could cause this, am I missing something? (Maybe something really obvious?)
Any help appreciated!
Use process explorer to check if the dll is loaded or not.
When you attach the process make sure that you are enabling both 'Native' and 'Managed' code type (in the code type selection option).
See also this question: Visual Studio is not loading modules when attaching to process
I encountered a similar issue after transferring a project from one computer to another. I will simply explain what I discovered and how I fixed it, and you can determine if it fits your problem and solution.
The work computer I wrote an application on contained a .dll file which my program was referencing. After moving the application to my home computer, the application could no longer locate the .dll file it was previously referencing because the file was no longer there.
The application compiled and ran even without the referenced resource (.dll file) because the previously compiled assembly (debug folder) contained its own copy of the .dll file and other resources. Put simply, it is the old assembly build that is running and not the current application you're working on. This is also why this error tends to suspend the designer window and throw an error after the app is done running.
I would take a look at the following:
a) Under Solution Explorer, go into the References folder and right click the missing reference node and select properties. In the properties box, observe the Path of the resource being referenced. Is the resource still located at this path?
b) Check the debug folder for a copy of the resource you're looking for. If the resource is there, make a copy and save it to your desktop. If it's not there, get the file from the original source.
c) Under Solution Explorer, right click 'Properties' and 'open'. From the menu that appears select 'Resources' from the left and at the top of the new window that appears you you should see 'Add Resource' with a small drop down arrow. Click the arrow and select 'Add existing file' and then browse to the file. If you don't see it you may have to change the file being browsed from the small drop down above the 'open' and 'Cancel' buttons. After the file is located it should create a new folder in the solution explorer called 'resources.' Now the file is a permanent part of your application and not merely a reference to it.
I had the same issue today with Visual Studio 2008. I was using a simple tester to test a new method in an assembly. So added a reference to my assembly I wrote the code to load the assembly and call the new method, build, everything OK. But during execution the debugger would throw an exception saying that new new method did not exist, and the modules window was empty.
Turns out the assembly I was modifying was in the GAC, and was using instead of the new one in my build directory.
I had the same issue with visual studio 2017 Pro and searched for a week but no luck then i installed VS2019 Pro and test with same project but the break point wasn't working at all and the project's DLL was missing from the modules list.
I was running multiple projects under one solution and i suddenly observed that if select project1 as "Startup Project" the DLL of that project is loaded only in the module list. So as i was testing an API and I switched API project as Startup Project and observed now the API DLL files are loaded into the modules list.
Right Click on your required project that you want to include it's DLL files in the module list and set it as "Startup Project"