Related
I have made a new build definition. Most options are kept on default. I'm just playing around for the moment.
Problem is that when I build my projects as release mode in Visual Studio 2013 all is good, not errors. When TFS builds it I have a few errors:
(I had to translate it from my own language to English, sorry for that)
TemplateService.cs (80): Core.Infrastructure.Objects.PredefinedTemplate does not contain a definition for TemplateId and there is no extentionmethod TemplateId found gevonden *(something with first argument)* of the type Infrastructure.Objects.PredefinedTemplate is being accepted (possibly missing a user instruction or an assmbly-reference)
The things I already did:
Set the copy local of the referenced DLLs to false and true again, as stated on some websites
Check the build definition if it cleans the workspace (it does)
Added assembly names to the objects in code. I.e.:
PredifinedTemplate to Core.Infrastructure.Objects.PredefinedTemplate
Whatever I do, I keep gettings these errors! Does anyone know what is happening?
UPDATE:
As stated by James Reed I have placed the referenced projects in NuGet packages. In the end I had to place two projects in NuGet-packages. The build on TFS works now and it even deploys to the server.
Using NuGet is not my first choice, because of debugging functionality. But for these two projects, that only holds objects and data-entities, it should not be a problem.
You are missing an assembly reference. i.e. the dll containing the definition for TemplateId is not available on the build server.
If this is defined in a project in the same solution, then something is wrong with the project reference, try deleting and recreating the reference.
If this is a binary reference then you have 3 options
Add the project to the solution and use a project reference.
Check the binary in to source control (not recommended)
Use nuget to manage your references
In a team project I'm working on, setting a breakpoint in a file (say IdeasController.cs) will lead to erratic debugger behaviour if there's another file with the same name in the solution. I've reproduced the problem on several developers' workstations.
Example
I set a breakpoint in IdeasController.cs in our Web API:
Another file called IdeasController.cs exists in our separate MVC 4 web project. In the screenshot below, the debugger shows the Api->IdeasController source code, but the line highlight matches the code structure of Web->IdeasController. The breakpoint is duplicated, with one of them in the middle of a comment block.
The Breakpoint window shows the breakpoint in both files simultaneously:
On some workstations the debugger steps through the correct lines (regardless of the line highlight); on others it cheerfully steps through irrelevant lines (including comments and whitespace). I'm guessing this depends on which source file it chooses to display.
What I've tried
I've trawled the Internet. This kind of problem seems to occur when there's a mismatch between the debug file (*.pdb), the source file, and the compiled code. There are a lot of possible causes: duplicate file names (which can confuse the debugger[5]), outdated project build files, invalid solution cache, or incorrect build configuration.
These are the solutions I've found and tried:
Checked my build configuration.
Made sure the project isn't built in release mode.
Made sure we don't have code optimization enabled.
Made sure the project's debug module was loaded correctly. (Started debugging the project and checked Debug > Windows > Modules. Both assemblies are listed, not optimized, and have a symbol status of "Symbols loaded".)
Reset the debugging metadata & Visual Studio cache.
Closed Visual Studio and deleted the solution cache file (*.suo).[1]
Deleted each project's build output (the bin and obj folders). (For future reference: open the solution folder in Windows Explorer and type this in the search box: "type:folder AND (name:=bin OR name:=obj)".
Deleted the assembly cache folder (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]
None of these had any effect. I can rename one of the files (without renaming the class) to temporarily work around the problem, but that's far from ideal.
Where I am now
Page 14 of my latest Google search. Suggestions would be much appreciated. :)
If no better alternatives exist, you could put the breakpoint in code:
System.Diagnostics.Debugger.Break();
Just don't forget to remove it afterwards...
I'm so glad I found this post, thought I was the only one and was going insane! I'm having the same problem in VS2012 with VB.Net and have tried everything the OP mentioned.
Unique naming of the files seems to be the only 100% fix that I've found. Disabling all breakpoints until the application has loaded and then re-enabling the breakpoints you need works most of the time. Breakpoints in Lambda functions can still give you issues.
I just had the exact same problem. What solved it for me was deleting the .suo files belonging to the solution that contained the affected project/source file.
I also deleted my local symbolcache but I don't think that had anything to do with it.
(My solution contains multiple projects, one file (DataAdapter.cs) in one project was affected by this (VisualStudio put my breakpoints in the pdb belonging to System.Data.DataAdapter). I opened the .csproj file directly and was able to correctly set the breakpoint.)
I had the same problem today. I was able to trace it back to the fact that I had forgotten to set the platform target to x86 while debugging. Unfortunately the others (x64 / Any CPU) can be problematic while debugging. At least VS 2008 doesn't like them. I guess this is yet another reason to stay away.
Some speculation... I think the debugger (while running a 64 bit app) somehow "steals" breakpoints away from a file in certain cases. For me it was because another assembly was loaded first which had the same file name. I was able to avoid the issue, even in 64 bit mode, if I first manually loaded the assembly with my breakpoints: Assembly.Load("MyAssemblyWithBreakpoints");
Hope this (my first stackoverflow contribution) helps.
Although renaming one of the files will work, I found that the simplest solution is to temporarily disable automatic loading of symbols for the "other" assembly.
Start the debugger and continue until you hit the erroneous breakpoint.
Find where the debugger actually set the breakpoint using the Call Stack window:
Right-click on the row with the yellow arrow and enable Show Module Names. (The row should also have the red breakpoint symbol on it.)
The assembly name is now visible on that row.
Find that assembly in the Modules window (Debug > Windows > Modules).
Right-click on the assembly and disable Always Load Automatically.
Stop the debugger.
Start debugging again.
By doing this, you're preventing the Visual Studio debugger from mapping the breakpoint to the wrong assembly. It will then load the symbols from the other [presumably] correct assembly first, therefore mapping the breakpoint to the correct assembly.
Why does this happen?
This seems to occur when two different symbol files (PDB files) — for two different assemblies — both reference a source file with the same name. Although the source files are completely different, the Visual Studio debuggger seems to get confused.
For example, imagine there are two different files both with the name IdeasController.cs. The first one compiles into assembly Api.dll, and the second one compiles into assembly Web.dll.
When the debugger loads symbols, it will either load Api.pdb or Web.pdb first. Let's say it loads Api.pdb first. Then even if you set a breakpoint in Web\IdeasController.cs, it will find a match for IdeasController.cs in Api.pdb. It then maps code from Web\IdeasController.cs to Api.dll. This won't map correctly, of course, and so you see all sorts of odd issues while debugging.
I just had this issue on Visual Studio 2017 (Version 15.9.7), were break points were skipped and the debugger just "jumped" over return statements etc.
After a while I noticed, that I've recently added a .runsettings file to the project - and it turned out, that in my case configuring the CodeCoverage data collector is causing this problem.
As soon as I removed this section:
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>
from the .runsettings file, it worked like a charm again.
I just backed up and deleted the file and then added back to the project, that solved the problem. I just whish i did it before going through the beforementioned list :)
You may also try to Clean and Rebuild (not Build) all projects.
I was hitting this issue in Visual Studio 2015.
I had a sub-folder with a DLL I wanted to save as Version1. It seems even after removing the reference to that DLL, and then adding a reference to another project studio pulled in the existing reference and went to the wrong source file. I removed that DLL in the sub-folder then Studio got the correct source.
I found a helpful link on [MSDN that shows how to clear prior associated source files in studio at this link][1].
Summary:
In the Solution Explorer, right click on the solution name (ex: Solution ‘TestApplication’) and select Properties This will bring up the Solution Property Pages dialog
Under Common Properties, select Debug Source Files
In the Search these paths for source code files (Visual Studio .NET 2003) / Directories containing source code (Visual Studio 2005) box, add, remove and/or reorder the directories as desired
Click the OK button
I was having the same issue. In my case both the projects had same port numbers. I was able to resolve it by changing the port number of the project whose file's breakpoints were not hitting.
My guess is that IIS Express was caching the pdb file from the second project since both files had the same name, and the projects had the same port number.
What worked for me (VS2017) was disabling this option in Tools --> Options... --> Debugging --> General: "Require sources files to exactly match the original version", which is enabled by default but I had it turned on.
That was not enough though, I also had to manually remove obj and bin folders for all projects in solution.
Delete all the .pdb files of the project where the break point is hitting wrongly. This will solve the issue.
It happened to me (in VS 2008) to have two child breakpoint with the same memory address and the same associated file.
Those breakpoints were spawned at a certain time during the running of the process.
I noticed that I had duplicated .dll files in my project folders, and resolved removing the duplicated .dll, while keeping only one .dll per name in the debugging folder structure. (As example in my case I had /bin/Example.dll and /bin/Plug-in/Example.dll both present under my debug folder structure).
I had a very similar problem. In my case the problem was a different target .net framework in one of the projects causing VS2017 to wrongly load a source file (with the same name) of another project, not the one being activated with
ObjectHandle handle = Activator.CreateInstance
Changing the project's target framework to be the same in all projects fixed it.
I had a similar issue with the breakpoint being set in another file with the same filename in a different project.
It was caused by the fact that the debugging was started for that other project, while it was not started for the project where I tried to set the breakpoint. The breakpoint creation worked correctly after doing the Debug > Start New Instance for the intended project.
I have read this post thoroughly: How does Visual Studio's source control integration work with Perforce? and found it very informative. However, I have a specific issue that is blocking my use of Perforce in VS.
For the most part, I have no complaints about the plug-in (I'm still using the P4VSCC plug-in because the new plug-in requires conversion by the entire team which can't happen at this time). Once I understood the idiosyncracies, I've had only one problem working with the plug-in.
Our solutions contains many projects that are built into a single deployment package. As such, each assembly is versioned the same. To accomodate this, and other common aspects, we have defined a common "SharedVersionInfo.cs" file which contains the AssemblyVersion and AssemblyFileVersion attributes typically found in the AssemblyInfo.cs file. This file is stored in an Assets folder beneath the solution folder and added to each project's Properties folder as a linked file. This works great from a version management perspective as we only have to change the version in one place and all assemblies are updated. However, Perforce has a problem with this when a new developer first opens the solution or when a new project is added. The only remedy we have currently is to remove all of the linked files (there are 3 per project in this solution), bind the project to source control, then re-add the linked files.
This isn't such a big deal when we add a new project but the solution contains 80 projects (and counting), so this isn't a viable remedy for a new developer!
My understanding is that the problem has to do with where VS thinks the binding root for each project is. After some research, I was led to find where the MSSCCPRJ.SCC files are for the projects. I found there are numerous SCC files scattered throughout the solution structure. So...
First question: Why are there multiple MSSCCPRJ.SCC files in my solution structure?
We also have several shared/common projects that we use in our solutions. This leads to the following folder structure:
/Source
/CommonTools
/ProjectA
ProjectA.csproj
/ProjectB
ProjectB.csproj
/MySolution
/Assets
SharedVersionInfo.cs
/Project1
Project1.csproj
/Project2
Project2.csproj
:
/ProjectZ
ProjectZ.csproj
MySolution.sln
Where both ProjectA and ProjectB are part of MySolution.sln
Second Question: How can I setup the bindings so the /Source folder is considered the root? This would ensure that all projects included in the solution are under the same binding root. Perforce considers this folder to be the root, how do I get VS and the plug-in to do the same?
Since no one else has offered up a solution, I thought I'd follow-up with my own findings for anyone else that comes across the thread.
First, I still have no idea why Visual Studio creates multiple MSSCCPRJ.SCC files but these are the key to establishing the "binding root" for a solution. It is critical that this file exist at the highest level necessary so that ALL of the projects in the solution are in sub-folders relative to the location of this file. In my example above, the MSSCCPRJ.SCC needed to be located in the /Source folder. Having it in the /MySolution folder caused the original problem when adding projects from /CommonTools into the solution.
That said, resolving the issue was no easy task. I had to manually edit the .sln and all of the .csproj files in Notepad. What I found was that some of the .csproj files had the following elements identifying the source control settings:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
I don't know what SAK stands for, but my understanding is this tells Visual Studio to use the binding information contained in the .sln file.
I had to change these to:
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
where the SccLocalPath value is the relative path from the .csproj file to the MSSCCPRJ.SCC file.
I also had to change the SccLocalPathX and SccProjectFilePathRelativizedFromConnectionX statements for each project in the .sln file. The SccLocalPathX value should be the relative path from the .sln file to the MSSCCPRJ.SCC file - a dot (.) if in the same folder. SccProjectFilePathRelativizedFromConnectionX should be the relative path from the binding root to the .csproj file.
I wish I could say that having that in place, I never had to repeat these steps. Unfortunately, I still have to go in and make corrections every time I added a new project to the solution. Visual Studio still wants to use SAK for the elements in the .csproj file and sometimes the values in the .sln file aren't quite right.
But, at least I know what to look for and what needs to be done to achieve my goals. If anyone else has a better solution or a way to configure VS and/or Perforce so these settings are created correctly up-front, I'll gladly give credit.
Hope that helps...
I have a Setup deployment project in VS 2010.
The project compiles perfectly with the GUI interface of VS 2010, but any time I trying to compile it via vs cmd (devenv.com) it comes up with this error:
ERROR: Unable to update the dependencies of the project.
Notice that there is NO dll that mentioned in the error (e.g. the error does NOT contain "The dependencies for the object ‘xxx’ cannot be determined").
Please do not tell me to clean all the files in this setup and start from ground up - this is not a real solution!
I have 5 projects with this exact error, and I don't want to re-arrange each one.
More then that, this does not promise me that the problem will not re-occur in the future.
Thanks very much!
I used to rebuild these installer projects from scratch when they stopped working (for whatever reason), but I've found a much much quicker (and less error-prone) workaround. It works for me. Maybe it will work for you.
Remove the Installer project from your solution through the IDE
interface
Add the Installer project back into your solution (Add >
Existing Project...)
Rebuild
It works practically every time for me...
The hotfix didn't fix the issue on my computer (tried on two computers, rebooted all that jazz)
Instead I used source control to figure out what happened to my .vdproj.
It appears extra corrupt entries are added to the "File" section of the .vdproj.
Suppose you are getting an error such as
ERROR: Unable to update the dependencies of the project. The dependencies for the object 'AutoMapper.DLL' cannot be determined.
In your .vdproj search for AutoMapper and you should come across several { } where it is used.
A normal one looks like this:
"{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_263299FB43D185D41A44FBEE0253D3ED"
{
"AssemblyRegister" = "3:1"
"AssemblyIsInGAC" = "11:FALSE"
"AssemblyAsmDisplayName" = "8:AutoMapper, Version=1.1.0.188, Culture=neutral, PublicKeyToken=be96cd2c38ef1005, processorArchitecture=MSIL"
"ScatterAssemblies"
{
"_263299FB43D185D41A44FBEE0253D3ED"
{
"Name" = "8:AutoMapper.DLL"
"Attributes" = "3:512"
}
}
"SourcePath" = "8:AutoMapper.DLL"
whereas a corrupt chunk is missing the name of the dll (AutoMapper.DLL in this case) in the ScatterAssemblies section.
Remove this corrupt entry, that is the entire section starting from "{9F6F8455-.. down to the next chunk.
I fixed this by editing the vdproj by hand and removing the Hierachy and File sections and then rebuilding the vdproj
see: Setup project error: Unable to update the dependencies of the project
This worked for me:
Run a clean solution command from VS2010
Open source code folder in explorer
Search for *.exe files, sort by location
Manually delete all files in Release folder
If there exists some_project.vshost.exe locked up file, open properties of this project in VS, and uncheck "Enable the Visual Studio hosting process" under debug. Then remove it as well. It should build now.
This is copied from #timB33's external link, which works. All links to the MS hotfix appear to broken, so this was the only way I could find to fix without removing and recreating the setup project.
I have consistently used this method to get around this bug instead of rebuilding my setup projects. This applies to both merge module projects AND setup projects. Manually remove the data in the Hierarchy and Files section of the project files.
Open .VDPROJ file
Find the "Hierarchy" section. Delete everything so the section looks like this:
"Hierarchy"
{
}
Find the "File" section. Delete everything so the section looks like this:
"File"
{
}
Reload the project
Rebuild the project.
You may need to re-add project outputs if missing something
support.microsoft.com/kb/2286556
thanks Hans, this update fixed my problem.
I'm working on a medium-sized project which uses qmake to generate Visual Studio 2005 project files. I'm trying to get it built under Visual Studio 2010 Ultimate. Since qmake doesn't support this IDE yet i had the provided conversion assistant convert my solution.
When trying to build I get the following error in one of the subprojects:
CVTRES : fatal error CVT1100: duplicate resource. type:VERSION,name:1,language:0x0407
After what Google's results told me it seems that this error is likely to occur when migrating to a newer version of Visual Studio but I don't know why and the hacks recommended there don't work for me.
What I already tried is to rename the ressources to random numbers, even a different "name" at every occurence of the version information.
When I build the project again after reading the error and deleting the corresponding .RC-file it works once. But that's too much of a hack.
Any ideas anyone?
Thanks in advance.
I resolved that problem when moving from VC++ 2010 to 2012 by changing the setting under Configuration Properties>Manifest Tool>Input and Output>Embed Manifest to NO. I have no idea what that is all about, but I looked at the contents of the .manifest file, and it sure looks like I can live without it being embedded.
I recently solved the similar problem with Qt 4.8.2 and Visual Studio 2012. Qt 4.8.2 does not support VS2012 as mkspec, so I copied win32-msvc2010 mkspec to win32-msvc2012 (changing _MSC_VER to 1700) and used some other workarounds (QtWebKit fix, etc. — you can find them over the internet) to build Qt 4.8.2 with VS2012. But qmake was not aware of VS2012 .vcxproj project files, so it continued to generate VS2010 projects. After conversion of these project files to the new 2012 format in the VS the above error arose.
The solution was to exclude generated .res files from build in all configurations (both Debug and Release). To do this, open 'Generated Files' folder in Solution Explorer, right click the .res file, open Properties, select 'All Configurations' from drop-down list and set 'Excluded From Build' property of 'General' section to 'Yes'.
It is quite tedious to repeat these actions by hands every time, so I wrote Python script to automate this. You can use it (at your own risk!) to update qmake-generated .vcxproj files.
import sys
import os
from xml.etree import ElementTree
def updateProject(filename):
def getXmlns(tag):
return tag[1:].split('}')[0]
tree = ElementTree.parse(filename)
root = tree.getroot()
xmlns = getXmlns(root.tag)
for cb in root.iter('{' + xmlns + '}CustomBuild'):
if(not 'Include' in cb.attrib):
continue
if(not cb.attrib['Include'].endswith('.res')):
continue
for excl in cb.iter('{' + xmlns + '}ExcludedFromBuild'):
if('Condition' in excl.attrib):
del excl.attrib['Condition'] # delete ExcludedFromBuild condition
ElementTree.register_namespace('', xmlns)
tree.write(filename)
if(len(sys.argv)>=2): # use project files specified in command line:
for i in range(1, len(sys.argv)):
updateProject(sys.argv[i])
else: # update all project files in current directory:
for filename in os.listdir(os.getcwd()):
if(filename.endswith('.vcxproj')):
updateProject(filename)
Thanks to Xandy for pointing out that you'll need to pass working directory to listdir() for script to work in Python 2.
If you ever encounter this error while compiling (usually a downloaded project from internet), then remove the manifest file and remove the reference to the manifest file in the .rc file.
Reference
I recently ran into this problem, and by accident ended up with a project file that didn't have the resource conflict. In my case I was importing a QT qmake generated project for VS2008 into VS2010. After using VcprojFormatter and a lot of diffs, I found the difference (for me). I think it is a bug in either the import wizard, or the core of VS 2010.
http://www.codeproject.com/KB/macros/vcproj_formatter.aspx
My resource file was called win32_resources.rc You'll need to edit each intermediate data folder corresponding to your build configurations (release, debug, etc)
Look for a section like the following in your vcxproj file:
<ItemGroup>
<Resource Include="debug\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">true</ExcludedFromBuild>
</Resource>
<Resource Include="release\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</ExcludedFromBuild>
</Resource>
</ItemGroup>
All the "Resource" text should be replaced with "CustomBuildStep":
<ItemGroup>
<CustomBuildStep Include="debug\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">true</ExcludedFromBuild>
</CustomBuildStep>
<CustomBuildStep Include="release\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</ExcludedFromBuild>
</CustomBuildStep>
</ItemGroup>
The problem in the VS2008 file is that the default(?) setting was not explicit:
<File RelativePath="release\win32_resources.res">
<FileConfiguration
Name="Debug|Win32"
ExcludedFromBuild="true"
>
<Tool Name="VCCustomBuildTool"/>
</FileConfiguration>
</File>
The "Tool Name" field was missing.
If you ever encounter this error while compiling (usually a downloaded
project from internet), then remove the manifest file and remove the
reference to the manifest file in the .rc file.
This answer by hB0 was 100% correct for the case I encountered.
This was very useful to me and I would like others to benefit from knowing this, rather than assuming hB0's answer should be ignored because others have votes and hB0's has zero votes. I have to say it in a separate answer because I the system will not let an unregistered user vote. I even registered so as to be able to vote on this answer but the system still will not let me vote till I am a more mature user.
This is a stretch, but I had a similar problem under Visual Studio 2005. It might help, or be totally off base:
I was linking with a static library (.lib) that has its own version resource - very reasonable, it shows the library's version. On some stations, my app would link. On other stations, I'd get the same duplicate resource message you got.
It turned out to be related to a linker optimization setting: "Use Library Dependency Inputs" (UseLibraryDependencyInputs=), possibly combined with "Link Library Dependencies". When "Use Library Dependency Inputs" was enabled, the linker was being fed the .obj and .res files that were used to build the .lib, instead of just searching the .lib.
The problem is that you don't want the .lib's .res file as an input file to the linker. My project has its own version resource. If you bring in the .lib's resources, you now have two version resources, hence the error. If the linker simply searches the .lib, it has no reason to bring in the .lib's resource, and all is well.
My project's configuration didn't force the setting of "Use Library Dependency Inputs", it inherited it. On some stations, it inherited "No", and I could link. On some stations, it inherited "Yes", and we got the error.
If Visual Studio 2010 still has this setting, try forcing it off.
I had this problem and it was resolved by ensuring any included .rc files were excluded from the build, except the main .rc that was #including the rest.
I had this problem and it was resolved by ensuring any included .rc files were excluded from the build, except the main .rc that was #including the rest.
by Richard Hein worked for me. I was compiling with VS2013.
I had similar problem in Visual Studio C++ 2010. I did not installed any Service packs or updates of VS and this problem arises when I had two rc files which tried to use ICONs. So I just taken content of one file and cut it into the main file. So only one file contains the ICONS and the second file is empty. Works like sharm :-).
Replace else block in Dmitry Markin answer to recursively update all project files
else: # recursively update all project files in current directory:
rootdir = os.getcwd()
for root, subFolders, files in os.walk(rootdir):
for filename in files:
if(filename.endswith('.vcxproj')):
filePath = os.path.join(root, filename)
print "file: %s" % (filePath)
updateProject(filePath)
I came here looking for an answer for this error. I am sorry to burst the bubble. None of the answers worked out for me.
My mistake was I had defined 3 MACRO's with same id. That is the reason I was getting the error mentioned in the question.
my code before when the error was showing:
#define IDB_MARKER_NORMAL_LINE 21**6**
#define IDB_MARKER_ARROW_LINE 21**6**
#define IDB_MARKER_DOTTED_LINE 21**6**
i changed it to:
#define IDB_MARKER_NORMAL_LINE 21**6**
#define IDB_MARKER_ARROW_LINE 21**7**
#define IDB_MARKER_DOTTED_LINE 21**8**
Errors were GONE!!!!!!!!!!
I had this and I did the following in resource.h
#undef VS_VERSION_INFO
#define VS_VERSION_INFO 310
As VS_VERSION_INFO is given resource id 1 in WinRes.h just making it something else fixed my issue.
If you ever encounter this error while compiling (usually a downloaded project from internet), then remove the manifest file and
remove the reference to the manifest file in the .rc file.
This answer by hB0 was 100% correct for the case I encountered.
This was very useful to me and I would like others to benefit from
knowing this, rather than assuming hB0's answer should be ignored
because others have votes and hB0's has zero votes. I have to say it
in a separate answer because I the system will not let an unregistered
user vote. I even registered so as to be able to vote on this answer
but the system still will not let me vote till I am a more mature
user.
This answer point a way to find the problem that I encounted. In my senario, the import props has this code:
<ResourceCompile Include="$(VersioningDir)**Version.rc" />
When I delete it, all work is done.
If you ever encounters CVT1100 (duplicate resource) & LNK1123 (failure during conversion to COFF) resource errors in Visual Studio 20XX, then do below steps to resolve it.
Open .rc file & comment / remove below MACRO
MOVEABLE PURE "res\.manifest"
2 Rename / Delete Manifest file from Resource folder from Project directory.
Now Re-build the solution & Enjoy...