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
- :
- Re: 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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 10, 2007
06:32 AM
Hey,
This is what I also faced with some time ago. It is really a stopper for installing ASP.NET application. I worked this around as follows:
Create an installer .NET class and override the Commit() method. In this method use .NET XML API to parse the web.config and correct all such inconsistencies.
As for me, I later decided not to use this component at all and switched to custom functionality. .NET installer classes accept parameters and leave the responsibility to you, but I'd prefer knowing what is going on instead of using black boxes thoughout the project.
Good luck 😉
This is what I also faced with some time ago. It is really a stopper for installing ASP.NET application. I worked this around as follows:
Create an installer .NET class and override the Commit() method. In this method use .NET XML API to parse the web.config and correct all such inconsistencies.
As for me, I later decided not to use this component at all and switched to custom functionality. .NET installer classes accept parameters and leave the responsibility to you, but I'd prefer knowing what is going on instead of using black boxes thoughout the project.
Good luck 😉
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 10, 2007
11:59 AM
Since both XML documents are valid, ASP.NET is obviously picky. I was reading this....
http://msdn2.microsoft.com/en-us/library/ms731049.aspx
Try changing
to
and see if IS ends up changing it to
Who knows, maybe it'll work?
Edit: Just tried it... no change. Hmmmm, I'll keep playing.
http://msdn2.microsoft.com/en-us/library/ms731049.aspx
Try changing
and see if IS ends up changing it to
Who knows, maybe it'll work?
Edit: Just tried it... no change. Hmmmm, I'll keep playing.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 11, 2007
11:36 PM
I've been speaking with Microsoft on this issue and our findings should be ready tomorrow.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
02:29 AM
That's great info, Christopher! Looking forward...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
06:23 PM
Please do tell.. I am having this issue now with a vb.net app config file. It wouldn't be a problem if the tags were side by side, but the setting is reading in as a carriage return and causing a crash.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 11, 2007
11:00 AM
I have the same result with my web.config file as well as any other xml file I try to configure with installshield. Very poor (pathetic even) for supposed new functionality.
My self written exe.config file parser can cope with installshields changes, so I left it in there, but I had to remove the xml files changes from my web project since it "broke" the web.config file.
My self written exe.config file parser can cope with installshields changes, so I left it in there, but I had to remove the xml files changes from my web project since it "broke" the web.config file.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 11, 2007
11:08 AM
I had an email thread going with a Microsoft Dev PM and I think he was close to admitting it was a bug in ASP.NET but I never received a reply and when my company was sold I lost access to all of my old emails.
I don't fault InstallShield here. They are using XMLDOM under the covers and this is a case of two Microsoft technologies not interacting well with each other.
I don't fault InstallShield here. They are using XMLDOM under the covers and this is a case of two Microsoft technologies not interacting well with each other.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 24, 2008
03:11 AM
Hi,
I know it's some time since the last posting in this thread, but I'm new to IS2008, and I have this same problem, and so far, after much searching in this fourm, I cannot find any solution.
How did any of the previous posters eventually get a working install of their web.config file?
Mike
I know it's some time since the last posting in this thread, but I'm new to IS2008, and I have this same problem, and so far, after much searching in this fourm, I cannot find any solution.
How did any of the previous posters eventually get a working install of their web.config file?
Mike
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 24, 2008
07:37 AM
IMHO, the problem is with ASP.NET as and should be equivilant. Now it would be nice if InstallShield didn't reformat entire documents when applying an XPath but that hasn't changed.
So us developers are kind of stuck between a rock and a hard place. Until one of those rocks budges, what I would do is write a custom action to execute after the IS XML custom action that fixes mangled clear elements.
So us developers are kind of stuck between a rock and a hard place. Until one of those rocks budges, what I would do is write a custom action to execute after the IS XML custom action that fixes mangled clear elements.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 24, 2008
08:24 AM
Thanks Christopher - that's very helpful.
I had concluded a few hours ago that was what I needed to do, and I'm now trying to put together a simple search and replace custom action, to execute after immediately after InstallFinalize, to get web.config, and simply search for , and replace it with , but, for the life of me, I cannot find any simple working Installscript example which lets me do that - I 've got a couple of examples, but they break.
Do you have any pointer to a simple funciton whcih actually works to do that replacement?
I think the real problem I'm experiencing is the Macrovision documentation.
Regards.
Mike
I had concluded a few hours ago that was what I needed to do, and I'm now trying to put together a simple search and replace custom action, to execute after immediately after InstallFinalize, to get web.config, and simply search for
Do you have any pointer to a simple funciton whcih actually works to do that replacement?
I think the real problem I'm experiencing is the Macrovision documentation.
Regards.
Mike
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 24, 2008
08:50 AM
Ah! At last, I've found a working example of a simple file search and replace. Many thanks to Mark Kendizor, who posted his FileStrReplace on installsite.org.
As a newbie to the Installshield products, I am amazed that every single step seems to be a struggle. I seem to be spending more time getting the Macrovision software to work than I am getting mine to work. That can't be right.
Many thanks to forum contributors like Christopher for helping to alleviate the problems this product presents for new users. Without that help, I'd be reaching for another solution right now.
Mike
As a newbie to the Installshield products, I am amazed that every single step seems to be a struggle. I seem to be spending more time getting the Macrovision software to work than I am getting mine to work. That can't be right.
Many thanks to forum contributors like Christopher for helping to alleviate the problems this product presents for new users. Without that help, I'd be reaching for another solution right now.
Mike
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)