diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
index 8f529a42..61e96600 100644
--- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
+++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
@@ -730,6 +730,8 @@ Unconstrained genericity, as in <code>C [G]</code>, is defined as equivalent to
 
 ==Assignment attempt==
 
+{{Caution|As of version 7.1, the assignment attempt has been marked as obsolete. Use the object test (described below) instead. This documentation will remain during a period of transition, but will be removed at some point in the future. }}
+
 The Type Conformance rule ( [[ET: Inheritance#Polymorphism|"Polymorphism"]] ) ensures type safety by requiring all assignments to be from a more specific source to a more general target. 
 
 Sometimes you can't be sure of the source object's type. This happens for example when the object comes from the outside -- a file, a database, a network. The persistence storage mechanism( [[ET: The Dynamic Structure: Execution Model#Deep_operations_and_persistence|"Deep operations and persistence"]] ) includes, along with the procedure <code>store</code> seen there, the reverse operation, a function <code>retrieved</code> which yields an object structure retrieved from a file or network, to which it was sent using <code>store</code>. But <code>retrieved</code> as declared in the corresponding class <code>STORABLE</code> of EiffelBase can only return the most general type, <code>ANY</code>; it is not possible to know its exact type until execution time, since the corresponding objects are not under the control of the retrieving system, and might even have been corrupted by some external agent. 
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki
index 744cab59..68e9e558 100644
--- a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki
@@ -332,7 +332,7 @@ No. There is a language facility called the '''object test''' which will come to
                 print (l_rect.width)
             end
 </code>
-In this code, the entity <code>l_rect</code> is a fresh local entity produced during the object test. So, the code can be read: if at this point, <code>my_polygon</code> is attached to an instance of type <code>RECTANGLE</code>, then attach that instance to a fresh local entity named <code>l_rect</code>, then apply <code>{RECTANGLE}.width</code> to <code>l_rect</code> and print the result.
+In this code, the entity <code>l_rect</code> is a fresh local entity produced during the object test. So, the code can be read: if at this point, <code>my_polygon</code> is attached to an instance of type <code>RECTANGLE</code>, then attach that instance to a fresh local entity named <code>l_rect</code>, then apply <code>width</code> to <code>l_rect</code> and print the result.
 
 
 :'''Note:''' The object test replaces the functionality of an obsolete mechanism called assignment attempt. Assignment attempt used the syntax '''<code>?=</code>''' in the context of assignment versus the '''<code>:=</code>''' of normal assignment.