N
~~~ .NET Ed ~~~
It is not the first time I have had to fight with ASP.NET stubborness. Maybe
this time it does what I need it to do.
My asp.net application uses a couple of custom web controls, each controls
has a separate assembly/dll. Then I have a test page for the controls,
obviously with reference to the assemblies containing the controls. It is a
test environment on my local computer so I know for sure there are no other
requests for the same page (or any of them).
The problem is, no matter how many changes I made to the control's DLL,
asp.net still INSISTS on using the old copy. I tried forcing recompilation
with dummy changes, removing and adding the reference to the DLL, removing
the bin/obj from the control's build tree. All of these to no avail, asp.net
still uses the old DLL. Changes are for a reason, why can't it see that if
the referenced DLL changed it is because there IS a need for a change. Isn't
that a clear "hello, I am new" message?
So, is there a way to forcibly invalidate the cache?
Thx,
E.
this time it does what I need it to do.
My asp.net application uses a couple of custom web controls, each controls
has a separate assembly/dll. Then I have a test page for the controls,
obviously with reference to the assemblies containing the controls. It is a
test environment on my local computer so I know for sure there are no other
requests for the same page (or any of them).
The problem is, no matter how many changes I made to the control's DLL,
asp.net still INSISTS on using the old copy. I tried forcing recompilation
with dummy changes, removing and adding the reference to the DLL, removing
the bin/obj from the control's build tree. All of these to no avail, asp.net
still uses the old DLL. Changes are for a reason, why can't it see that if
the referenced DLL changed it is because there IS a need for a change. Isn't
that a clear "hello, I am new" message?
So, is there a way to forcibly invalidate the cache?
Thx,
E.