Search code examples
c#asp.net.netvisual-studiobackport

I need to update decompiled class in .NET is this the correct way?


Right now I'm backporting issues that were fixed in a new version and adding them to an old version. It is .NET and Im using Visual Studios so once I add the code it seems it needed to be added to a decompiled class that will only allow me to read-only. What I did was copy the full path and I was able to write to the file itself and now my changes work. My main question is Im new to working with files that are decompiled and wanted to know if this is the correct way to make changes to a decompiled class. Note the class is serialized and just using enum only so I only added one new enum to the class. Again is there a better way to use Visual Studios to make decompiled updates, or did I do this incorrectly? Right now I can find it in the solution and when I copied the path this was the basic path "C:\User\name\AppData\Local\Temp\MetadataAsSource(guid id)\DecompilationMetaDataAsSourceFileProvider(guid id)\decompiled.cs"?


Solution

  • Well, you don't need or want to de-compile such referenced assemblies each time.

    I would assume that you have source code to that assembly. And if you don't, then create a project, de-compile, and get a working build for that class.

    Once done?

    Then you are free to include that assembly as a reference in your projects.

    To make changes to that referenced assembly?

    You close the current project, open the project with the referenced assembly. Make source code changes (commit your changes to GitHub if using source control). Then you build.

    You then close that project, and re-open your existing project.

    If you are making lots of changes to that referenced assembly? Then simply include that project into the current project. That way, you can always edit the source code, and at build time, the. ddl’s will be re-created each time.

    This is why you have the option to include multiple projects into one project.

    Doing above also means that hitting shift F2 to jump to that class in code will NOT decompile, but jump to the source code for that class.

    Keep in mind that the option to include "multiple" projects is allowed for most types of projects, but one exception is using a asp.net web site. Such a web site does not have a .sln (project file), and thus you don't have the option to include or "enjoy" multiple projects during the development process.

    However, if you use a asp.net web site "application", then you do have a project file.

    So, the standard approach for referenced assemblies?

    If you need to modify source code of referenced assemblies (class)? Then you close your current project, open the project with the assembly, and then make changes to that source code. You then build, close the project, and go back to your existing project.

    As noted, for "some kinds of active" development, this can be a pain. However, you can of course keep 2 copies of Visual Studio open.

    The preferred approach is to simply add that project to your existing project.

    Thus, multiple projects are allowed in one project.

    You see in "bold" which project is the root, or "main" project, and it looks like this in practice.

    enter image description here

    And if you right click on either project?

    You can choose "Build Dependencies".

    So, this:

    enter image description here

    And in above panel you can use drag + drop to change the build order.

    In above I have an external referenced project (CONTROLMIS), and thus that needs to be built BEFORE the main project builds. So, in above order, that project should be moved to the top and appear before the main project.

    Thus, you are free to edit source code in both projects, and from your point of view, only one build process is required.

    So, this is the "general" approach when you need to frequent edit external class assemblies you are working with.

    As noted, this option requires your project is a "asp.net web site project", and you not using "just" a asp.net web site which does not have a .sln project file.

    This ability (of multiple projects in one project) is one significant reason to use a asp.net web site project as opposed to working with a asp.net web site. Even rather old projects have the above options.