错误 6 Invalid Resx file. Could not load type Vidicon.MainApp.VidiconPropertity, Vidicon.MainApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null which is used in the .RESX file.  Ensure that the necessary references have been added to your project. 行 133，位置 5。 F:\setup\av\视频监控\VidiconApplication\Vidicon.MainApp\VidiconPanel.resx 133 5 Vidicon.MainApp

这到底是个什么错误呢？关掉VS，重开，就好了。
今天关掉重开也不行了。
连微软也没有解决方案啊：http://connect.microsoft.com/VisualStudio/feedback/details/113060/invalid-resx-file-could-not-load-type


这里有一篇介绍ResX文件的。

ResX File References

Both versions of the .NET Framework allow files such as bitmaps to be included in resources. These files are included through two methods: file embedding and file referencing. Both versions of the framework support both methods. The difference between the two methods lies solely in the packaging of the original resource source. When a file is embedded in a resource, the file's complete data stream is copied from the original file into the resx file, and the original file is no longer needed. When a file is referenced in a resource, the resource simply contains a link to the original file and both files are needed. The Visual Studio 2005 Resource Editor uses file references to add files to a resource. The Visual Studio 2003 Resource Editor has no direct support for adding files to a resource, so the method chosen depends on the approach that you take (see the "Adding Images and Files in Visual Studio 2003" section of Chapter 3, "An Introduction to Internationalization"). The following resource entry represents a bitmap that has been embedded in a .NET Framework 1.1 resx file:

<data name="NationalFlag" type="System.Drawing.Bitmap,
System.Drawing, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" mimetype="application/x-
microsoft.net.object.bytearray.base64">
<value>
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4
c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAH
UwAADqYAAAOpgAABdwnLpRPAAAAMtJREFUOE+lks0NwjAMhR8zeSdPwaFrd
AFG4YDcK10CifbMwTwnVVvET1Jq6ZOjKHmxn3MQbR1dB0BIxLJu0zr4ESIU
gDqErDPXBimCENDWXDWzFvKKoIB6EJcjs5W5EhNWUCAJAE2+FHlqJfb9MRR
JLZwug9vNU9YwdRI1pQ8FcgVrUiVsi0J+bIosFZi7kVmQIjUxm7iMMPshFS
OMMaPv+9eHwrgNgTSmytc+nYO1NIsf6V9wv56Ls/72H8Zx9P0tvJm4wcA4u
ruCJ1wJmJQKMPjaAAAAAElFTkSuQmCC
</value>
</data>

The following resource entry represents a bitmap that has been referenced in a .NET Framework 2.0 resx file:

<data name="NationalFlag"
type="System.Resources.ResXfileref, System.Windows.Forms">
<value>ResourcesNationalFlag.gif;System.Drawing.Bitmap,
System.Drawing, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
</value>
</data>

Notice that the type is no longer a System.Drawing.Bitmap, but a System.Resources.ResXfileref. In the value element, you can see the file reference (ResourcesNationalFlag.gif) and also the type of the contents of the file (System.Drawing.Bitmap). From the point of view of the resource assembly that gets compiled from these resources, there is no difference between resources that are referenced and those that are embedded because the file references are resolved before the assembly is generated, and the resulting assembly contains the complete "embedded" definition of the resource (so the referenced files do not need to be deployed and are not required at runtime). From the point of view of version control, the benefit of using file references is that you get better granularity of resource versioning. From the point of view of code that processes resx files, the distinction between referenced and embedded is important. Recall our first code snippet, which read a resx file and added the contents of each DictionaryEntry into a ListBox. This code will most likely fail if it processes a resx file with file references. The ArgumentException that occurs reports the problem:

ResX file Could not find a part of the path
'C:BooksI18NTestsVS2005WindowsApplication1inDebug
ResourcesNationalFlag.gif'. Line 329, position 5. cannot be parsed.

Recall that the file reference is to "ResourcesNationalFlag.gif"i.e., a relative reference, not an absolute reference. The path is relative to the executing assembly, so it looks in the WindowsApplication1inDebugResources folder and not the WindowsApplication1Resources folder, where the files are. If you are using the .NET Framework 1.1, the simplest solution is to use absolute file references. If you are using the .NET Framework 2.0, you can tell the ResXResourceReader where to find the resource files using the ResXResourceReader.BasePath property:

ResXResourceReader reader =
new ResXResourceReader("Form1Resources.resx");
reader.BasePath = @"....";

Alternatively, a more generic solution to the same problem is to simply set the BasePath to the same folder as the resx file that the ResXResourceReader is processing:

string fileName = @"C:AppsWindowsApplication1Form1Resources.resx";
ResXResourceReader reader = new ResXResourceReader(fileName);
reader.BasePath = Path.GetDirectoryName(fileName);

The new support for file references that was added in the Visual Studio 2005 Resource Editor has an implication for code that processes resx files. As we have already seen, the code that reads entries using a ResXResourceReader works well in both the .NET Framework 1.1 and 2.0, as long as resources are embedded or absolute file paths are used. The Visual Studio 2005 Resource Editor, however, defaults to file references (using relative paths), so code that processes resx files that worked under the .NET Framework 1.1 will mostly likely fail when processing the .NET Framework 2.0 resx files (because the file references are relative) and must be updated to set the ResXResourceReader's BasePath property