CodeElement2.RenameSymbol Method

Changes the declared name of an object and updates all code references to the object within the scope of the current project.

Namespace:  EnvDTE80
Assembly:  EnvDTE80 (in EnvDTE80.dll)

Syntax

'Declaration
Sub RenameSymbol ( _
    NewName As String _
)
void RenameSymbol(
    string NewName
)
void RenameSymbol(
    String^ NewName
)
abstract RenameSymbol : 
        NewName:string -> unit
function RenameSymbol(
    NewName : String
)

Parameters

  • NewName
    Type: String

    Required. The name of the symbol to rename.

Remarks

If any part of the rename cannot be completed (within the current project scope), the method returns an error.

Note

You cannot call RenameSymbol or ElementID latebound. (For example, DTE.ActiveDocument.ProjectItem.FileCodeModel.CodeElements.Item("Class1").RenameSymbol("Class2").) You must explicitly cast the object to the CodeElement2 interface before making the call.

Code elements in EnvDTE80 (hereafter called Code*2 objects) derive from those in EnvDTE. (For example, CodeClass2 derives from CodeClass, and CodeElement2 derives from CodeElement.) Internally in Visual Studio, all code elements (in both assemblies) are in turn cast to CodeElement2. So, logically, it is as if CodeClass2, for example, ultimately derives from CodeElement2.

Since the two elements are in reality in two separate inheritance hierarchies, though, the latebinder cannot look up CodeElement2 methods on Code*2 objects. EnvDTE works essentially the same way, but the use of pre-processor macros allows the interfaces to be defined such that inherited methods are explicitly defined on all of the related interfaces for which conversions exist. EnvDTE80 interfaces are defined using a similar inheritance scheme, only without the use of pre-processor statements. This is a more elegant solution since it eliminates redundant properties, but the result is that the properties cannot be called latebound. To work around this issue, explicitly cast the object to the CodeElement2 interface before making the call.

Also, the values of code model elements such as classes, structs, functions, attributes, delegates, and so forth can be non-deterministic after making certain kinds of edits, meaning that their values cannot be relied upon to always remain the same. For more information, see the section Code Model Element Values Can Change in Discovering Code by Using the Code Model (Visual Basic).

.NET Framework Security

See Also

Reference

CodeElement2 Interface

EnvDTE80 Namespace

Other Resources

How to: Compile and Run the Automation Object Model Code Examples

Discovering Code by Using the Code Model (Visual Basic)

Discovering Code by Using the Code Model (Visual C#)

Implementing and Using Automation Extenders