C # Add a Win32 resource file to the Project

This kind of thing is annoying, it hurts, especially it hurts. It took me a day.

There are several methods, which are especially annoying. One is build event and the other is msbuild.

Build event today

1. In build events, pre-build

Input:

copy  $(ProjectDir)Time/norlib.Time.Holidays.xml  "$(TargetDir)norlib.Time.Holidays.xml"set VCInclude=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\includeset SDKInclude=C:\Program Files (x86)\Windows Kits\8.0\Include\umset SDKShared=C:\Program Files (x86)\Windows Kits\8.0\Include\sharedecho $(IntermediateOutputPath)set RCDIR=IF EXIST "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\rc.exe" (set RCDIR="C:\Program Files (x86)\Windows Kits\8.0\bin\x86\rc.exe")echo  (%RCDIR%  /i "%VCInclude%"  /i "%SDKInclude%" /r /fo "$(IntermediateOutputPath)\res1.res" "$(ProjectDir)Controls\OpenFileOrFolderDialog\res1.rc")if not defined RCDIR ( echo "Error! Unable to find rc.exe.")  else  (%RCDIR%  /i "%VCInclude%"  /i "%SDKInclude%" /i "%SDKShared%" /r /fo "$(ProjectDir)res1.res" "$(ProjectDir)Controls\OpenFileOrFolderDialog\res1.rc")if not defined RCDIR (Exit 1)

It mainly starts from the second line.

First, note that many of the following Macros in C # are invalid, such as $ (vcinstalldir), and write macros and VC point to different directories, such as fucking: $ (frameworksdkdir)

This macro $ (frameworksdkdir) points to: C: \ Program Files (x86) \ Windows kits \ 8.0 \ inside bin \ x86. We can find rc.exe.

But under C #, point to: C: \ Program Files (x86) \ microsoft sdks \ windows \ v8.0a \

Instantly dizzy, Google found a post for half a day:

Http://go4answers.webhost4life.com/Example/get-winsdk-configuration-tool-work-41266.aspx

He said:

After some investigation and reflecting using Redgate Reflector, I found that the variable $(FrameworkSDKDir) will always resolve to the 6.0a installation if that SDK is installed and the target framework is 3.5. This is due to a possible bug in the .NET Type Microsoft.Build.Shared.FrameworkLocationHelper, in assembly Microsoft.Build.Utilities.v3.5, Version=3.5.0.0 that shipped with .NET Framework 3.5. The problem I see is in the property PathToDotNetFrameworkSdkV35 in this class. It first reads the registry value for SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\InstallationFolder, while I believe it should actually first read SOFTWARE\Microsoft\Microsoft SDKs\Windows\CurrentInstallFolder. I worked around this problem by hacking the key SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\InstallationFolder to point to 6.1. This enables me to use rc.exe from SDK 6.1, while it might affect other products that expects to retrieve the 6.0a installation folder from the registry.I have the following questions regarding the issues described above:Why would rc.exe install  to different locations on two otherwise seemingly equivalent machines? Is the code that I refered to in Microsoft.Build.Shared.FrameworkLocationHelper affected by a bug? and if soIs there a work around / fix other that the method that I described?

It is quite troublesome to solve the problem. As you can see, I created a % macro % in build events.

For example:

set VCInclude=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\include

Note that you cannot write vcinclude =... in this way, macro becomes % vcinclude % ...... and double quotation marks are not required.

After the compilation is successful, we have a res file, which is hard to get.

C # project property-> application-> resources-> resource file (radio button): Enter the absolute path of the res file.

In this way, the Win32 resource file can be added.

It's fun.

Refer:

Http://stackoverflow.com/questions/8057080/how-to-embed-a-resource-in-a-net-pe-executable

Http://blogs.msdn.com/ B /astebner/archive/2006/02/28/541036.aspx

You still need to go to msbuild later