One option is to add traces to the page. It makes things easier to 'debug'
in production, as you can have your client run the page and examine the
trace. This allows you to see what is going on wtihout having to send back
files.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss
or just read it:
http://gregorybeamer.spaces.live.com/
*************************************************
| Think outside the box!
|
*************************************************
"Josh Valino" <no spam please> wrote in message
news:%...
> Sorry, I should stated that. No, it doesn't show up. So, it seems to be
> executing. The DLL that contains the value of this property is identical
> (according to Beyond Compare 2, so they say), so I have reason to believe
> that the property does still have a value. The only thing I can come up
> with is that someone deleted the line out of the aspx file for some
> reason. I'm waiting for them to send me the file but I figured I'd venture
> into the remote possibility that it's an IIS configuration option.
>
> Thanks
>
>
> "George Ter-Saakov" <gt-> wrote in message
> news:...
>> Check the source. Do you see <%=...%> in HTML.
>> If yes then .NET is not installed in IIS and IIS serves the page as is.
>>
>> George
>>
>> "Josh Valino" <no spam please> wrote in message
>> news:...
>>> Hi,
>>>
>>> I have a client that has our product and in one of the aspx files, there
>>> is code like this:
>>>
>>> <%= SomePublicProperty %>
>>>
>>> where the public property returns a string. In the test environment at
>>> the client's site, the value is being REsponse.Written as expected. In
>>> their production environment, it is not. No errors or anything. It's
>>> just as if that <%= %> line doesn't exist at all. Is there anything I
>>> should know about at the IIS level, where they may perhaps have disabled
>>> server-side scripts in aspx files?
>>>
>>> Thanks
>>>
>>
>>
>
>