>The error message says it all. ALL Attributes are written to the EXE at compilation so only constants make sense as parameters.
>Where in the soap extension do you want to use this information?

It seems from the point of origin, which is at the WebMethod() level, that nothing has been firing yet in the application. This seems to happen at the very first and that would explain why my framework object does not live yet. It is very sad that we cannot link any object to a SOAP extension, as once we are in it, we cannot benefit of any framework or application functionalities.

The only way I have found to establish some kind of communication between the application and the SOAP extension is to store something in the System.Web.HttpContext.Current.Items object, from the SOAP extension, such as System.Web.HttpContext.Current.Items("HTTPInputStream") and make use to that from the application later on. But, this is only a one way only. I cannot do it in the reverse way.

This is something Microsoft should enhance in its Web Service infrastructure. We should be able to deal with low level SOAP envelope, either at the Request or Response level, in a conventional way.

For example, we can call our classes from the SOAP extension, by initiating a call to an object of our application created from the SOAP extension. But, that is not the same as gaining access to an object that lives at the Web Service level, as anything in it, simply does not exist yet when the SOAP extension is called for the first time and cannot be seen either after the deserialization as we simply cannot communicate between both tiers.