This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- XML File Update Changes The Way Tags Are Closed?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 22, 2007
12:22 PM
XML File Update Changes The Way Tags Are Closed?
I have an installscript setup project that is using the XML file changes function in the IDE to update the web.config file for a website that I am installing. One thing that I have noticed is that when you have a self-closed XML tag in the file it becomes a non-self closed tag after IS processes the file. So for example, becomes .
In most cases this has not been an issue for us, but there is one place where this behavior is undesirable. We have a section in our web.config file to configure the ASP.NET membership provider that looks like this:
You will notice that the first thing inside of the element in this XML snippet is a self-closing tag to remove the default .NET provider before registering our own provider. After IS updates this file (even though it is not specifically updating anything in this section) I end up with the following xml:
When this happens, and we try and launch the website we get the standard ASP.NET error page complaining that the tag is an unrecognized tag. What we have found is that when the tag in this section is modified to it gives this error.
So far this is the only place that the XML behavior of IS (replacing self-closing tags) has caused us problems. Although, both forms of XML should be valid, I still question why it is that IS is modifying the XML in this manner to begin with??? Is there a way we can prevent IS from doing this and causing us this problem?
In most cases this has not been an issue for us, but there is one place where this behavior is undesirable. We have a section in our web.config file to configure the ASP.NET membership provider that looks like this:
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="CS_UserData"
applicationName="SalesBuyDesign"
enablePasswordRetrieval="true"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
passwordFormat="Encrypted"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression="" />
You will notice that the first thing inside of the
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="CS_UserData"
applicationName="SalesBuyDesign"
enablePasswordRetrieval="true"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
passwordFormat="Encrypted"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression="" >
When this happens, and we try and launch the website we get the standard ASP.NET error page complaining that the
So far this is the only place that the XML behavior of IS (replacing self-closing tags) has caused us problems. Although, both forms of XML should be valid, I still question why it is that IS is modifying the XML in this manner to begin with??? Is there a way we can prevent IS from doing this and causing us this problem?
(11) Replies