I converted a working project from Visual Studio 2008 to VS2010. The c++ solution builds a single executable and 3 DLLs, and a windows installer project.
After converting to VS2010, I received a build error "Unable to build custom action named 'Primary Output from xxxx (Active)' from project output group 'Primary Output' because the project output group does not have a key file."
I removed and re-added the output groups, then attempted to add a custom action. The executable output was not listed as a candidate for a custom action. I then noticed when I selected the executable "Primary Output" properties, that the "KeyOutput" property was set to (None) and was grayed out.
When revisiting the VS2008 version, the KeyOutput property was not grayed out. I found the error message on MSDN, with a useless fix:
"Remove the custom action and replace it with a custom action pointing to a project output group that has a key file."
Obviously the tech writer didn't know how to fix it either. Keep in mind the original build worked and installed correctly. I believe the root issue is why the KeyOutput property is disabled - but why? (When viewing "Outputs" it correctly shows the exe or dll in each project)
I had a similar problem and I figured out why the setup project could not find the key output files.
My project Output Directory was defined as $(SolutionDir)\bin\$(Platform). SolutionDir already has a trailing backslash so the \bin was placing a double backslash in the path. The project would build fine but the setup project couldn't resolve the key outputs. Setting the output to $(SolutionDir)bin\$(Platform)\ resolved the issue.
After further investigation, I found this is a bug in Visual Studio 2010.
If you specify an output name for a project that differs from the name of the project itself, it fails to do the right thing.
To reproduce this, change
Project properties->Linker->General->OutputFile from $(OutDir)$(TargetName)$(TargetExt) to be something like $(OutDir)foobar.exe
The project then changes the KeyOutput value to empty, and is not available for custom actions in installations. No workaround other than living with the default project naming convention.
Very late answer but hopefully it will save someone the 2 hours I spent banging my head on the wall with VS 2010 ( what an awful piece of software it is - slow to load and takes up 300 megs of working memory per devenv , and now this bug!!!!!????) here goes -
Roger Dunn was correct is saying that it is the Project properties->Linker->General->OutputFile that causes the problem - if you have something like $(OutDir)foobar.exe the custom action barfs , if you change it back to $(OutDir)$(TargetName)$(TargetExt) it works again!
The work around is to change the macro $(TargetName) to foobar and then user $(OutDir)$(TargetName)$(TargetExt) if you want custom name for your exe.
$(TargetName) can be changed at - Project properties->Configuration Properties->general->TargetName.
But what a waste of time this VS 2010.
Related
I am using Visual Studio 2022.
I would like to build a project using BJFX.
It is my first BGFX project but I have some issues in the first stage.
I have this error message in the console #error "BX_CONFIG_DEBUG must be defined in build script!".
What is the build script? How can I define this so call BX_CONFIG_DEBUG script or whatever that is?
To be fair, I don't even understang the issue, except that something isn't properly defined.
Does anyone know the issue and how to fix it?
At first, I thought it was an issue occurring from the installation of Visual Studio.
I tried re-installing Visual Studio but it didn't work.
I have looked for a solution on many forums and Youtube but nothing worked for me.
The messaage you are seeing is being emmited by the BGFX headers telling you that you need to define BG_CONFIG_DEBUG. By Build Script this means however you build your code (In this case using VS2022).
I'm going to presume that you're using the GUI.
In the Solution Explorer, right click your app name and select Properties
Now open Configuration Properties->C/C++->Preprocessor:
Here you will find Preprocessor definitions add BX_CONFIG_DEBUG (each value seperated by the ; symbol.
Save settings. Thats it.
I am using Visual Studio Community Edition 2017 and trying to create a UWP application.
I get the following error
Your project is not referencing the "UAP,Version=v10.0.10240" framework. Add a reference to "UAP,Version=v10.0.10240" in the "frameworks" section of your project.json, and then re-run NuGet restore.
I had the same issue on my build machine. What's weird is everything runs fine on my local machine.
I managed to fix this by going into the project properties for my UWP app, and changing the Target version to match the Min version.
The reason I believe this issue is happening is because when targeting a higher framework, on a Windows Server machine (the build agent) it doesn't restore all of the packages between your min and target version. It seems to build fine against the version you target.
By the way Ken, following the instructions given by the error don't fix the issue. Try not to be so rude. I came to this page looking for the same issue, and you are no help at all.
I have the same issue, after I remove my bin and obj folder, I can build mine and see the errors gone.
I recently ran across this same issue when updating the target framework. The issue turned out to be the Nuget Restore task in my VSTS Build definition needed to be updated to the latest version (2.*). Once I did that, the builds worked as expected.
I agree with Jeff. Ken Not sure if you should be giving any answers with this kind of attitude.
The error message is misleading there is not project.json at least you cannot see it in the Visual Studio explorer.
I had the same issue and have min and target version set to the same number but it would not build.
The fix was to make sure in Nuget package manager setting to tick checkbox 'Allow Nuget to download missing packages' and the one below it as well and rebuild the project.
This is a pretty weird mistake, but what worked for me :
1st Solution:
1 - Change your project target to "10.0.10586" (or up)
2 - Make a clean / nuget restore / rebuild
3 - Return the project target to the "10.0.10240"
4 - Make a clean / nuget restore / rebuild
Do not ask me why, but it worked :)
2nd Solution:
If you use a repository with Tortoise, try making a CLEANUP
I had an old Backup folder in my project that contained a project.json. Looks like it might have been from an earlier upgrade. I deleted Backup and got a good build.
This happens in exactly this manner, if projects were generated in the year 2017 in the phase where MS changed to project.json and then decided against it. I tried several solutions (and yeah, Ken White is so wrong!) and the cleanest way was to really build up a new clean project in the lastest and up to date version of Visual Studio (VS2015 did not work sustainable) and just copy over the old project content which is just a few minutes work. This will save you a lot of headaches especially working in a larger team!
I tried the above solutions but nothing worked. I had to backup and remove the UWP project and recreate it from scratch.
I tried a couple of solutions.
Solution 1
Open the solution from Windows explorer and search for project.json files. Open all of them (If you have multiple) and make sure the required framework versions are there. I frequently switch between build 10240 and 17763 and I get this error frequently. (I switch between git branches that target different frameworks of UWP) So instead of adding the exact version I just added only the 10.0 part like this.
"frameworks": {
"uap10.0": {}
},
Now if your project.json files are ok, search for project.lock.json files. If you have one or more of those, delete them.
Now clean your solution
Close VS
Delete all the bin and obj folders.
Reopen the VS and try to run the app.
Solution 2:
Go to project properties
Change the minimum and target version to something else and do a clean build. Then put the actual versions and build again.
I ran into this problem today while migrating a VS2008 solution to VS2010. The problem occurred in either of the following scenarios:
Rebuild Solution
Clean followed by Build Solution
If I did a second Build after either of these, the problem did not show up. Using Google, all I really came up with was year-old blogs from Microsoft saying they are unable to reproduce the problem, or that it is fixed in a future release.
The best thing I found was here: Mikazo Tech Blog: Solve MT.exe Errors in Visual Studio 2010
In the above article it said that the problem is related to Manifest generation, and that the solution is to turn off Manifests in settings under Linker-->Manifest. I don't need Manifests for this project, but I still wasn't satisfied.
I have solved this, and am simply going to answer my own question, because I haven't found this specific error (code 31) on StackOverflow.
WARNING: This exact error can also happen as a result of having a Windows Explorer window open in the folder containing the *.exe which you are currently attempting to build.
For example: Explorer open in /.../MyProj/Debug/ while trying to build the Debug version of your code in Visual Studio.
I was angry with myself for ~10min before realizing this.
Using process monitor and dbgview I discovered msmpeng (Microsoft Security Essentials) was accessing the file, just when mt.exe wanted to have it exclusively. Excluding the development directory solved the problem.
It is still a workaround of course.
In my projects, the Intermediate and Output directories were set to:
Intermediate Dir : $(Configuration)\
Output Dir : $(SolutionDir)bin\$(Configuration)\
Under C/C++-->Output Files, I had the following:
ASM List Location : $(IntDir)\
Object File Name : $(IntDir)\
Program Database File Name : $(OutDir)\$(TargetName).pdb
Under Linker-->Manifest File, I had:
Manifest File : $(IntDir)$(TargetName)$(TargetExt).intermediate.manifest
The cure was to remove the trailing \ from my C/C++-->Output Files section (because it's already part of those variables):
ASM List Location : $(IntDir)
Object File Name : $(IntDir)
Program Database File Name : $(OutDir)$(TargetName).pdb
Normally, the double-up of using $(IntDir) or $(OutDir) with a trailing \ doesn't seem to cause trouble, even though it's bad practice. I can't remember now whether I did it by accident or if the conversion process did it, but for whatever reason, it seems to have been messing up MT.exe.
I hope this is useful to anyone else who encounters this problem. Your settings may well be different, but consider that it may be related to improperly formed filenames.
Try turning off Windows Defender (or possibly other anti-virus related software). Windows Defender is known to lock files because MT.EXE runs after the linker is finished. WD jumps in the middle to check up on the newly built EXE and locks it up for the MT.EXE.
Giving credit to https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c5a3e2c3-fbf4-4268-a551-8cee195be586/test-case-13-for-vista-certification?forum=windowscompatibility, I found this was resolved by fixing the '-' character in the post build commandline. I believe some bad copy/paste efforts have replaced a hyphen with a dash.
deleting the "program debug database" in "debug" folder worked for me.
This problem happened when I was running the .exe in the debug folder on high priority.
Run VS as administrator. It solved the problem for me.
I have a project (*.sln) written in visual studio c 8.0. It was migrated to VC10 recently. When I choose the "Release mode", it was compiled sucessfully. But if I choose "Debug mode", the error " MSB6006 mt.exe code 31" happened.
I found that, in the debug mode, it used a wrong sub-project to startup.
After fixing the startup sub-project, it goes fine so far.
---- new status ---
This won't fix the problem. It just makes the problem disapear temporalily by rebuilding-all. Also, there are other faults caused by the migration. The "resources.h" is missed from the new project and the "winres.rc" is shorten.
In my case it was a problem with TortoiseGit. Removing Debug and Release folders from the GIT repository solved the problem.
Check if you have any anti-virus software like AVG. Exclude the manifest files in the anti-virus software exclusion list.
Look for an MSB8012 warnings. Likely you have a different output specification for the C++ output value and the Linker Output value.
Try Sysinternals/Procmon and filter on process = "mt.exe". It might tell you that a build input cannot be found.
I'm setting break points in Visual Studio before running the Local Windows Debugger, and they all say this when the debugger is running, with a small warning label on each break point. I can't see why this would be happening; people have talked about using different versions of Visual Studio and getting this error, but I made this project earlier today, pasting the base code from my professor into a new project created on my copy of Visual Studio 2012.
I found this when trying to fix a strange error in my program that wouldn't go away even though I manually fixed things (it was a string error that claimed I was using an index outside the bounds of the string; setting this value to 0 explicitly did not fix it) so I presume that this is the actual culprit.
Make sure you're properly building the code (Build Solution or Rebuild Solution).
In the output panel you should now be able to locate where the binaries are located.
Make sure you're debugging the said binaries by looking in the Debugging page of your project properties, the Command property should most likely be set at $(TargetPath).
Other things to look for. The project should be "Set as startup project", the program database option should be activated (by default). Don't modify the source after you started debugging.
I'm developing a unit test project (let's say XXX.UnitTest) to test ViewModels in another project (XXX) in my solution. I can add the reference but when I build, an error states that it cannot find that same project (XXX)
Error 42 Could not load file or
assembly 'XXX, Version=1.0.2.66,
Culture=neutral, PublicKeyToken=null'
or one of its dependencies. The system
cannot find the file
specified. XXX.UnitTest
I did a clean rebuild of all projects in my solution.
I verified that the assembly with that version number (1.0.2.66) did exist in the path I was referencing.
I removed and re-added the reference both as a project and through the Browse tab.
I made sure that the version number was not specified in the csproj file.
I verified the referenced assembly with Dependency Walker.
I verified that both projects were targeting the x86 platform. (As suggested here Tips to help debug "Could not load file or assembly X or one of its dependencies")
Does anyone know what else can cause this problem?
Last week I had this same problem. It turns out my solution and projects were on a network resource. If I moved the solution to the local drive, the problem went away.
This problem happened regardless if I used a mapped drive or an UNC path.
This problem happened even with a Code Access Security Policy of "Full Trust" for the URL.
I believe the problem occurs on Windows XP computers and not Windows 7 computers, but have not tested or verified.
I believe it has something to do with the Share permissions.
If I try to use "offline folders" for the network resource, I get "access is denied".
-.
Setting NTFS permissions has no effect.
Adding user to administrators group has no effect.
I did not test to see if problem exists on removable local drives.
Work Around
Move solution and projects to a local hard drive.
Comment
I think this is a bug in Visual Studio 2010.
I came across this post while searching for the answer. Here is the solution. In the config file of QTAgent32.exe and devenv.exe in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, add the following element to the section:
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
This can be added to machine config file (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config\ machine.config) for all VS2010 tools. Be sure to run notepad as administrator to allow machine.config to save.
See this link for details: http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx
I have the same problem. I'm running VS 2010 on Windows Server 2003; both running within a VM on a Mac. My VS project is in the mac home folder (~/) which is mapped as Z:\ from the Windows side. At build time, VS studio generates an error saying it can't find the UnitTests.dll or one of its dependencies. I get the same error with a small test project. If I move the project to the Windows C:\ drive, the dll reference resolves and unit tests work. I tried to add the reference Blanthor mentions, but couldn't get it to work.