Silverlight controls--How to improve application trust and problem resolution

Starting with SILVERLIGHT5, you can check the project settings to "require elevated trust when running in the browser" to achieve the purpose of running the Silverlight client within the browser, which is useful in a feature.

But I encountered a strange failure using this feature: I developed a SILVERLIGHT5 project using Visual Studio 2010 and found that the above setting item did not work, whether or not it was checked, the code App.Current.HasElevatedPermissions always returns false, and the actions that require power to run will naturally fail. After thousands of brain cells were exhausted, the cause of malfunction was found.

When you tick "trust that requires elevation when running in the browser," Visual Studio does the following:

1. Add content to the Silverlight project file (. csproj):<requireinbrowserelevation>true</requireinbrowserelevation>

2. Add a file to the Properties folder of the project: Inbrowsersettings.xml.

3. Add content in the Silverlight project file (. csproj): <inbrowsersettingsfile>properties\inbrowsersettings.xml</ Inbrowsersettingsfile>

If the above steps are completed smoothly, there is no problem. However, if the project's Properties folder has exactly one file named Inbrowsersettings.xml, the following failure may occur:

1, this file is only in the folder, not included in the project, then Visual Studio Add Inbrowsersettings.xml will fail, but will not give you any hint. The result is a "trust that needs to be promoted when running in the browser" This item has been checked, but in fact there is no successful promotion of Silverlight running permissions, the need to power to run the code will fail, this inexplicable failure to make my head. To resolve this failure, you can view all the files in Solution Explorer, manually include the Inbrowsersettings.xml in the project, and use Notepad to open the project file manually add the <InBrowserSettingsFile> Properties\inbrowsersettings.xml</inbrowsersettingsfile>. If you check "require elevated trust when running in the browser", it is found that Visual Studio does not add the Inbrowsersettings.xml file in the Properties folder to determine if the failure has been triggered.

2. This file is already in this folder and is included in the project. Visual Studio will try to change the contents of the Inbrowsersettings.xml based on your tick, if the Inbrowsersettings.xml file is in a read-only state (for example, it is checked in), then visual When studio changes the contents of the file, it goes wrong, and the result is that Visual Studio simply crashes and exits without giving you any hints before exiting. So if the Inbrowsersettings.xml file has been checked in or read-only for other reasons, check it out or remove the read-only attribute before changing the "trust that needs to be promoted in the browser" check.

In the above two faults, the 1th fault reason is very concealed. I used to wonder why so coincidentally, in the Properties folder there is a file named Inbrowsersettings.xml. It was not a coincidence that the reason was only known after asking colleagues. My colleague once tried to tick "trust that needs to be promoted while running in the browser," and Visual Studio added Inbrowsersettings.xml to his project, and he canceled his operation by undoing the checkout project after he had finished the test. He thinks it's a complete rollback of his actions, but it's not, undo checkout is just undoing the inclusion of the Inbrowsersettings.xml file in the project and not deleting the file in the project folder, so when he checks in the project again, Inbrowsersettings.xml will be checked in to TFS, and another colleague who gets the new version will take the Inbrowsersettings.xml file that is not included in the project to the Properties folder, which causes the fault from the face.

Hope to help everyone, no more people stepping on this mine.