I have got this result when using https://doc.qt.io/qt-5/qcommandlineparser.html#addHelpOption:
Использование: ./build/Debug/client/myapp [параметры]
Параметры:
-h, --help Displays help on commandline options.
--help-all Displays help including Qt specific options.
-v, --version Отобразить информацию о версии.
As one can see, the help entries are not traslated.
I tried to find a more full qt_ru.qm file or a qt_ru.ts file, but failed. How can be this fixed? Any ideas, please?
UPDATE (THE SOLUTION)
For those who are interested. I was inspired by the answer of user HiFile.app - best file manager below. I have not found qt_ru.ts. Instead, in my OWN myapp_ru.ts file I added the text below, and suddenly it turned out to be enough to translate the --help and --help-all entries:
<context>
<name>QCommandLineParser</name>
<message>
<source>Displays help on commandline options.</source>
<translation>Вывод справки по параметрам командной строки.</translation>
</message>
<message>
<source>Displays help including Qt specific options.</source>
<translation>Вывод справки с особыми параметрами Qt.</translation>
</message>
</context>
The translation files (*.ts) are in Qt sources, so you need to install Qt framework with source files. The text you are referring to can be found in Src/qttranslations/translations/qtbase_ru.ts. It depends on the Qt version which you are using, but AFAIK it seems to be translated in the latest Qt 6.4. If it is not translated in your Qt version, you can update the *.ts file yourself and convert it to *.qm using Qt Linguist application.
I upgraded an OCX library from VS2010/Win7 to VS2019/Win10. The project builds, however when I try and use RegSvr32.exe from an elevated command prompt, I receive error 0x0040200. I did a bit of debugging and the offending call is the call to AfxOleRegisterTypeLib.
Yes, I saw this SO article, which states that "absence of a tlb file near the dll". Other searches state to run from an administrative command prompt.
I do NOT have a TLB near the OCX control. If I try and create one using tlbexp.exe, I get the following error:
TlbExp : error TX0000 : Could not load file or assembly 'file:///C:\pathto.ocx' or one of its dependencies. The module was expected to contain an assembly manifest.
TlbExp command line (used Run as Administrator for all cmd.exe):
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\tlbexp.exe" /VERBOSE "<path to OCX file>" /out:"<path to .tlb output file>"
I downloaded Resource Tuner and that shows the manifest nicely. The manifest does not have any TLB information.
I am thinking that maybe the OCX manifest needs something more that helps TlbExp get at the information that it wants, just a thought.
<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity version="1.0.0.0" name="DriveOps.ocx"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
</application>
</compatibility>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
</assembly>
I did use Depends64 (aka Dependency Walker 64-bit) and there are no missing components DLLs. It finds all of them nicely, as does RegSvr32.exe.
Placing the OCX file in C:\Windows\System32 does not help.
To anyone looking at the DLLs, these same DLLs work fine on the Win7 box. Here is some more information on the non-Windows DLLs
PlxApi720_x64.dll: PLX v7.2 API (The Broadcom PLX chip is a PCIe switch (think USB/network switch, just w/PCIe lanes)
LSIDirectAccess.dll: The LSI API is a self-contained DLL that allows the software to talk to the LSI HBA RAID adapter
Ipp*.dll: The Ipp prefix are the DLLs used by the Intel Code Composer Studio redistribution (x64) files, here version 2011, an older one that needs to be updated to the latest and greatest, not to mention now free API. These are all in the System32 folder.
Here is the code:
// DllRegisterServer - Adds entries to the system registry
STDAPI DllRegisterServer(void)
{
AFX_MANAGE_STATE(_afxModuleAddrThis);
if (!AfxOleRegisterTypeLib(AfxGetInstanceHandle(), _tlid))
return ResultFromScode(SELFREG_E_TYPELIB); // <- failure line, through debugging
if (!COleObjectFactoryEx::UpdateRegistryAll(TRUE))
return ResultFromScode(SELFREG_E_CLASS);
return NOERROR;
}
The Intel Code Composer Studio 2011 files are in the C:\Windows\System32 directory, just like on the Win7 box.
For what it is worth, TlbExp fails on the Win7 box too, just it registers, which is probably why the UI can add the control. As I recall, I once replaced the OCX on the Win7 project and VS2010 automatically created the TLB and prefixed Ax in front, but that was a couple of years ago, so my memory may not be the most accurate. Attempting to add the OCX to the UI (.Net WinForms) fails miserably and just says could not be added.
The OCX does use the latest platform tool set (Visual Studio 2019 (v142)).
A comment for developer newbies, regasm.exe is for .Net Assemblies. RegSvr32.exe is for ActiveX Controls (OCX/DLL), which is what I have. RegSvr32 is for dynamically loaded modules, hence the DllRegister entry point.
Thoughts?
Notes From Further Testing
(Saturday 9/21/2019) When I upgraded, I created an empty C++ DLL project and then added all the files, changing the target extension to OCX going through the old project settings and when reasonable aligning them to the new project file wanting to keep things the same. I wanted to do a test and see what happens with a brand new OCX project. I saw that there was such a thing as "MFC ActiveX Control" for a project type in VS2019. I created that and saw that I got different base files, but more importantly RegSvr32.exe works. That means that either the mistake was the initial project file, so I need to import to a clean project or import piece by piece, if that is possible, and see where things break.
(Saturday 9/21/2019) The new test project did not come with a manifest file and TlbExp.exe failed with the same error message like my real project. I went to add new item and saw "Package Manifest". That manifest file, though still produces the same TlbExp.exe error, looks quite different from the application manifest file from above. I created yet another new MFC ActiveX Control project and added in the manifest from above just changing names and saw that the project refused to build throwing 1) Error c1010001 Values of attribute "level" not equal in different manifest snippets. and 2) LNK1327 failure during running mt.exe. That tells me that the original Win7 project and my Win10 project files probably have some error in it, otherwise VS should have thrown these errors to me. That does not answer why even on the test project TlbExp.exe fails. Maybe some attributes in the manifest are required. I just left the defaults.
Package Manifest
(It is the first time that I ever saw one of these. I always saw the app.manifest kind.)
<?xml version="1.0" encoding="utf-8"?>
<!-- TODO: Make sure to set the Package attributes -->
<Package xmlns="urn:Microsoft.WindowsPhone/PackageSchema.v8.00"
Owner=""
OwnerType="OEM"
Platform=""
Component=""
SubComponent="Package"
ReleaseType="Test" >
<Components>
<Driver InfSource="$(_RELEASEDIR)$(TARGETNAME).inf">
<Reference Source="$(_RELEASEDIR)$(TARGETNAME)$(TARGETEXT)" />
<Files>
<!-- For kernel mode drivers, $(DRIVER_DEST) evaluates to "drivers" by default -->
<!-- For user mode drivers, $(DRIVER_DEST) evaluates to "drivers\umdf" by default -->
<File Source="$(_RELEASEDIR)$(TARGETNAME)$(TARGETEXT)" DestinationDir="$(runtime.system32)\$(DRIVER_DEST)" />
</Files>
</Driver>
</Components>
</Package>
This article has an interesting approach, namely create a C++ DLL and then call LoadLibrary(dll) and after that GetProcAddress(module, "DllRegisterServer") to see which one fails. Well, in my case the both functions succeed. That means that the author missed one other failure branch and these two API calls are not the only thing that RegSvr32.exe does.
Though I am still not at the end of the road, as I have aximp.exe / tlbimp.exe issues on the OCX, I found the problem that prevented me from registering the ActiveX control, which was the question here.
The answer is the GUID in the main CPP file:
(I am giving my research, as I could not find anyone explaining how RegSvr32.exe works and what it does. I wanted to share in hopes that it helps others.)
const GUID CDECL _tlid = { 0xFE5C7D88,0xD53C,0x4977,{0xBA,0x56,0x4B,0xF3,0x02,0x0A,0x5D,0x8A} };
which gets used in the main registration function STDAPI DllRegisterServer(void) must match the GUID present in the IDL:
[uuid(FE5C7D88-D53C-4977-BA56-4BF3020A5D8A), version(1.0),
helpfile("DriveOps.hlp"),
helpstring("DriveOps ActiveX Control module"),
control]
library DriveOpsLib
{
...
}
I had 2 different values, hence the failure.
Here is the methodology and research that I used to find the problem, but first I will state the registration function, as that is key again.
STDAPI DllRegisterServer(void)
{
AFX_MANAGE_STATE(_afxModuleAddrThis);
HINSTANCE hiTypeLib = AfxGetInstanceHandle();
if (!AfxOleRegisterTypeLib(hiTypeLib, _tlid))
return ResultFromScode(SELFREG_E_TYPELIB);
if (!COleObjectFactoryEx::UpdateRegistryAll(TRUE))
return ResultFromScode(SELFREG_E_CLASS);
return NOERROR;
}
The failure was at this line, as I believe was mentioned in the question.
if (!AfxOleRegisterTypeLib(hiTypeLib, _tlid))
I had already found the source code for RegSvr32.exe on the internet. It was part of Microsoft GitHub sources located in VCSamples-master.
Direct Link to RegSvr32.exe: here
Direct Link to download zip: here
The code was a sort of dead end, as it told me what should have been obvious, namely that utility called the DllRegisterServer entry point of a DLL to do all the work. I should have known that, but, well, I had to see it to make sense.
Using procmon.exe, did not shed any light and the various calls to the registry was like reading a foreign language, not helpful.
Here I drew a blank until it occurred to me to get the source code for AfxOleRegisterTypeLib, as that what was failing. I wanted to see what the heck that thing did and what was at line 113 of source file ctlreg.cpp.
I was still thinking on the comment of procmon and a registry issue, but I figured that the code will tell me which one. It took me a bit of research, but I found the code. I love Microsoft sharing code. Their error messages are not helpful, but being able to actually see what they were trying to do so totally helps.
Here is the code:
BOOL AFXAPI AfxOleRegisterTypeLib(HINSTANCE hInstance, REFGUID tlid,
LPCTSTR pszFileName, LPCTSTR pszHelpDir)
{
USES_CONVERSION;
BOOL bSuccess = FALSE;
CString strPathName;
TCHAR *szPathName = strPathName.GetBuffer(_MAX_PATH);
::GetModuleFileName(hInstance, szPathName, _MAX_PATH);
strPathName.ReleaseBuffer();
LPTYPELIB ptlib = NULL;
// If a filename was specified, replace final component of path with it.
if (pszFileName != NULL)
{
int iBackslash = strPathName.ReverseFind('\\');
if (iBackslash != -1)
strPathName = strPathName.Left(iBackslash+1);
strPathName += pszFileName;
}
if (SUCCEEDED(LoadTypeLib(T2COLE(strPathName), &ptlib)))
{
ASSERT_POINTER(ptlib, ITypeLib);
LPTLIBATTR pAttr;
GUID tlidActual = GUID_NULL;
if (SUCCEEDED(ptlib->GetLibAttr(&pAttr)))
{
ASSERT_POINTER(pAttr, TLIBATTR);
tlidActual = pAttr->guid;
ptlib->ReleaseTLibAttr(pAttr);
}
// Check that the guid of the loaded type library matches
// the tlid parameter.
ASSERT(IsEqualGUID(tlid, tlidActual));
if (IsEqualGUID(tlid, tlidActual))
{
// Register the type library.
if (SUCCEEDED(RegisterTypeLib(ptlib, T2OLE((LPTSTR)(LPCTSTR)strPathName), T2OLE((LPTSTR)pszHelpDir))))
bSuccess = TRUE;
}
RELEASE(ptlib);
}
else
{
TRACE1("Warning: Could not load type library from %s\n", (LPCTSTR)strPathName);
}
return bSuccess;
}
I kept receiving an ASSERT, so although line 113 did was on a non-code line, the actual failure was obvious. I knew that I did not fail out on the ASSERT_POINTER, as that error message is different, which meant that I failed at:
ASSERT(IsEqualGUID(tlid, tlidActual));
I looked at the code in detail as well as the entry arguments. I decided to copy and paste this function contents into the real registration code in my OCX to gain further visibility while debugging. I wanted to see the values.
Sure enough, I saw 2 different GUID values, one from the top, my _tlid, and the one returned from the instance handle. I took out my handy-dandy TextPad text editor, though Visual Studio has a Find in Files, but TextPad is so much easier to use. That led to one other instance in the entire solution, namely in DriveOps.idl. That file up until that moment meant nothing to me, but suddenly I saw that the GUID here was the one that RegSvr32.exe pulled from the instance handle.
I unified the IDs, rebuilt, and now RegSvr32.exe no longer complains. Yeah, since I got the code, it had no choice but to register. That it does not modify the registry is a different story and problem from what I can tell, but that is another question. RegSvr32.exe now registers without complaint.
(Yes, I still have tlbimp.exe, aximp.exe, and adding my OCX project to my WinForms project problems, but I got this thing licked and learned something in the process. I guess the difference in line numbers may be some changes Microsoft made in the header, either way, functionality appears the same.)
Great. Issue in all such cases is the IDL has a different GUID as compared to what the DLL / OCX has in code for registration. How it changed, I did not investigate but was able to fix this issue by reading new GUID from project generated *.idl file.
I have a pretty straight forward WiX project. Nothing fancy. When trying to perform a MajorUpgrade over an existing installation, it is unable to start the service and inevitably rolls back to the previous version and starts the service just fine. I have removed the Start="install" and manually started the application successfully, so I know it's not a dependency issue.
I have searched endlessly and found no answers to my problem.
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." Schedule="afterInstallFinalize" />
My service install:
<ServiceInstall
Id="ServiceInstaller"
Type="ownProcess"
Name="LsdnService"
DisplayName="Lsdn Service"
Description="Placeholder for now."
Start="auto"
Account="[SERVICEACCOUNT]"
Password="[SERVICEPASSWORD]"
ErrorControl="normal"/>
<ServiceControl Id="StartService" Start="install" Stop="both" Remove="uninstall" Name="LsdnService" Wait="yes" />
I dumped the MSI log to a file and got this error but it is quite vague.
MSI (s) (18:48) [22:41:27:349]: Note: 1: 2205 2: 3: Error
MSI (s) (18:48) [22:41:27:349]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1920
There are some registry modifications during an installation. The installer attempts to read from the registry and inherit the already existing values.
<Property Id="LSDNADDRESS" Value="127.0.0.1">
<RegistrySearch Id="LsdnAddressProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnAddress" Type="raw" />
</Property>
<Property Id="LSDNPORT" Value="9920">
<RegistrySearch Id="LsdnPortProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnPort" Type="raw" />
</Property>
<Property Id="LSDNKEY" Value="6f380b07-0b54-4904-8303-95d1ec45d453">
<RegistrySearch Id="LsdnKeyProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnKey" Type="raw" />
</Property>
Debugging Results: Following a lot of debugging (by original poster - OP) this turned out to be a known MSI issue described here:
https://wix-users.narkive.com/EMfQPDrM/a-bug-get-reg-sz-when-using-type-integer. Nice search work.
What is in a DWORD? (a REG_SZ apparently): Essentially MSI "converts" a DWORD value found via a RegistrySearch
operation to a formatted string - REG_SZ - during upgrade
installations (could be more involved too). This causes services that
expect a DWORD value to fall over on startup during major
upgrades. A very exotic error.
Workaround: One can try to "solve" this problem by making the service code capable of reading both DWORD and REG_SZ.
This yields a more robust solution than solving the problem in a
custom action since it is a "permanent" fix as long as the code is in
there (and the presence of the code alerts other developers about the
problem). Or maybe use only REG_SZ?
Quick Checks: Check the service password and login - obviously. Anything in the
Event Viewer? Windows Key + Tap R + eventvwr.msc + Enter. How to use the Event Viewer to troubleshoot problems with a Windows Service. Perhaps you can try to do a folder diff on the before and after folders and see if you see something unexpected in
the config files? Naturally there will be lots of binary
differences, but check the text files (also encoding). Check the MSI log file
again and search for "value 3" as described here: Tips For Checking MSI Log
Files. Manually copy the new files in place and attempt to start the service via the services.msc applet.
Service Experts: Windows Services Frequently Asked Questions (FAQ). Content seems to be up to date - at face value at least.
These guys claim to be experts on services. I have no idea who they
are.
Look in the "Errors" section in the link above. Here are some
extracts:
1053: The service did not respond to the start or control request in a timely fashion
Why doesn't my Windows Service start automatically after a reboot?
1069: The service did not start due to a logon failure
Generic Check Lists: If none of the above does anything, maybe try these "torpedoes full spread" check-lists (just ideas to start debugging):
Desktop applicaton not opening after installation in client system
Windows Application Startup Error Exception code: 0xe0434352
General Purpose Debugging: Throwing in some general-purpose debugging approaches.
Custom Action Debugging: WIxsharp debug custom action in console
Dependency Scanning: Which winform project files should be packed up into the installer
Some Further Links:
C# Debug folder when copied to another location does not run the exe
wix service install not enough permission
How exactly does the WiX 'Service Install' work internally?
WiX Toolset PermissionEx Problem - App Does Not Run After Installation
It certainly could be a dependency issue. For example, GAC / WinSXS files don't get installed into the GAC until the commit phase which is after StartServices.
I would leave the Start="Install" in and while it's sitting at the failed to start prompt inspect the state of the machine and debug the service start manually. I bet you'll find something missing.
In short, using a .runsetting unit test file in a build step on TFS 2015 results in a 503 Service Unavailable exception.
After extensive searching and testing on a new TFS 2015 installation (as also described in TFS2015 new install, 503 Service Unavailable), I may have found the problem.
We are using .runsettings files as described on https://msdn.microsoft.com/en-us/library/jj159530.aspx, in a 'Visual Studio Test' build step on our new TFS2015 installation, as soon as the VSTest.console.exe is called, the next three application pools on the TFS server crash, resulting in a 503 Service Unavailable error:
DefaultAppPool
Microsoft Team Foundation Server Application Pool
Microsoft Team Foundation SErver Message Queueu Application Pool
First my .runsetting file was kind of large, but i did try the next one (I think as small as possible):
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Configurations for data collectors -->
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<!-- Match assembly file paths: -->
<ModulePaths>
<Include>
<ModulePath>.*\.dll$</ModulePath>
<ModulePath>.*\.exe$</ModulePath>
</Include>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
<ModulePath>.*fluentassertions.*</ModulePath>
<ModulePath>.*\.test\.dll$</ModulePath>
</Exclude>
</ModulePaths>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
When using this one, the app pools crashes. Even if i remove the part entirely, it will not work.
As soon as the next line is called (taken from the log lines of the build step), the app pools crashes.
Executing C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe "D:\TfsAgents\Agent1\_work\2\s\[...]\Release\Microsoft.QualityTools.Testing.Fakes.dll" "D:\TfsAgents\Agent1\_work\2\s\[...]\Release\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll" "D:\TfsAgents\Agent1\_work\2\s\[...]\Release\MyClassLib.dll" /Settings:"D:\TfsAgents\Agent1\_work\2\s\[...]\test.runsettings" /EnableCodeCoverage /logger:trx
If you look at the DataCollector tag in the .runsettings file, you see the version is set to 14.0.0.0. If you look at the page of Miscrosoft, they state that it should be 11.0.0.0, but also this version does not work. I thought it might be that version 11.0.0.0 was wrong, so I opened the dll with Telerik JustDecompile, and saw that the 'real' version was 14.0.0.0, so I put that version into the runsetting-file. But no luck.
So for now I'm just remove the runsetting file from the definition of the build, which unfortunately results in a wrong code coverate percentage.. So hopefully someone might have the answer for this.
This problem is limited to the specific runsettings file when used with build agent running on the same machine where IIS server is hosting TFS. There is a workaround available. Within DataCollectors->Configuration->CodeCoverage tag in runsettings file you can add following xml tags with given values :
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>false</CollectAspDotNet>
This should solve the issue, and also its recommended that in future if you are using runsettings file with Code coverage in Data Collector then these tags should be added.
I'm using Windows XP Professional SP3 and recently switched to Visual Studio 2010 Professional SP1 to work on a C++ project.
If I try to right-click on a project inside Solution Explorer and select "Add" >> "Resource...", I get this error popup window:
"The operation could not be completed. Unspecified error"
And then the only option is to click "OK".
Anyone else encountered this?
I had this same problem.
Right clicking on the project, selecting Unload Project, then right clicking again and clicking Reload Project fixed it.
So I'm not 100% sure of the exact reason for this, but it had something to do with the Code Browsing Info DB that I had disabled to speed up VS2010. Seems VS won't allow entering the Add Resource wizard if the Code Browsing Info DB is disabled.
Still with the DB re-enabled I got the hanging "Please wait while 'Resource Script Wizard' prepares to start. Click Cancel to end 'Resource Script Wizard'" prompt. Not sure how it finally disappeared, but I had to do a reboot and did close my Outlook mail client after the reboot while doing a couple more trials. Not sure if it has anything to do, but after that I was able to enter the Add Resource Wizard.
Maybe the good old Microsoft-style troubleshooting reboots still works after all these years.
In my case, it was cause by Google Recaptcha control.
I'd generate ressource after my page was completed so he catch my recaptcha Control but added a weird tag in his XML document.
Here is what I propose to you, open your resources file using XML editor and check out if there is not a weird tags which is widely different than other one. Maybe for me it's recatpcha, but maybe for you it's another third party.
Check out mine what it looks like :
<!-- OTHER TAGS --->
<data name="aControlResource1.ToolTip" xml:space="preserve">
<value />
</data>
<!--
THIS IS THE NASTY TAGS ... REMOVING IT MAKE IT WORKS PERFECTLY.
-->
<assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<data name="recaptchaResource1.ErrorMessage" type="System.Resources.ResXNullRef, System.Windows.Forms">
<value />
</data>
<data name="anotherControlResource1.ToolTip" xml:space="preserve">
<value />
</data>
<!-- OTHER TAGS -->
Yes i had same problem, the solution its simple, you should close resource file then u can insert another image resource, Visual Studio cant add ids to bitmap while the file steel open "resource.h"