XML File Update Changes The Way Tags Are Closed?

[swalkertdci]

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:

     

      
        
        
             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 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:

     
      
        
        
             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 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?

[Gwynbleid]

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 😉

[Christopher_Pai]

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.

[Christopher_Pai]

I've been speaking with Microsoft on this issue and our findings should be ready tomorrow.

[Gwynbleid]

That's great info, Christopher! Looking forward...

[gtzpower]

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.

[reckface]

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.

[Christopher_Pai]

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.

[MikeAtSoftware]

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

[Christopher_Pai]

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.

[MikeAtSoftware]

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

[MikeAtSoftware]

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