Big Problem with Server Side Includes (SSI)

[james_w4]

We're experiencing a major problem with Server Side Includes that are written
in ASP.NET / C# code, i.e.

<% Response.WriteFile ("/includes/en/header.inc"); %>

Most of the time Contribute CS3 behaves well and the SSIs work as you'd
expect. When in Edit mode the SSI content isn't visible, but this isn't a
problem as the Editable content can still be accessed. However, if a template
is changed in Dreamweaver, and the updated page subsequently edited in
Contribute, Contribute attempts to save the SSI content in the actual .aspx
file. So rather than saving an .aspx file with the C# include code, the content
of the .inc file becomes "hard coded" in the .aspx file.

This is a major issue and the only way I've found to overcome it is to delete
the connection in Contribute and then create a new connection every time a
change is made to one of our templates. Refreshing the templates by choosing
New... Refresh Templates -> for all websites works occasionally but not
reliably. For one user this is not the end of the world, but getting all our
users to delete and recreate their connections every time a template has
changed is not possible.

The problem seems to be related to Contribute "caching" an old version of the
template, and then thinking that the template for the page being edited is
different to the actual template used to create the page. It only occurs when
the template has been changed from the version that existed when the Contribute
connection was created. The only solution I can think of is to use Dreamweaver
Library Items instead of our SSI approach - however the site has 500+ pages and
LBI's don't offer the flexibility that we require from SSIs.

This is a major issue for us - please can anyone help?

[Charles_G]

Do you update the template, then log into Contribute before editing?
Contribute only downloads templates right when you first connect to a site.

A) Close all contributes
B) Update Template
C) Open Contributes
D) connect to site
--- this will cause the templates to update.
--- are u getting the error at this point?
--- or, are you getting it while logged in and have not gotten the
updated templates?

[james_w4]

(sorry for the delay in replying, first day back at work after holiday...)

Simply "reconnecting" to Contribute (i.e. closing then reopening after
uploading the new template) doesn't seem to solve the problem - only deleting
the connection entirely then re-establishing it ensures that the SSI code is
handled correctly (I'm assuming because the latest template is being correctly
used).

Moreover - getting every Contribute user (we only have a handful at the moment
but this may grow) to delete and re-establish their connections isn't reliable,
especially as the "problem" doesn't report itself well and you need to
understand what is going on to realise that there is a problem at all.

I guess what I really need to get to the bottom of is why on some occasions
the .aspx file is saved with the correct original SSI code (<%
Response.WriteFile ("/includes/en/header.inc"); %>) and sometimes the actual
contents of the .inc file are saved ("hardcoded") into the .aspx file. If it
is related to the latest version of the template being used, and the only way
to overcome this is to request everyone deletes and re-establishes their
connections then this is what we'll have to do - but if there is anything else
I can do to ensure Contribute NEVER hardcodes the SSI code then this would of
course be the best solution.

Any other ideas?

Thanks again for your help.