Microsoft Technology Licensing, LLC

Tomas Matousek

John Lawrence Hamby

Manish Kumar Jayaswal

Isadora Sophia Garcia Rodopoulos

Andrew Casey

Stephen Harris Toub

Gregory Bernard Miskelly

Jared Porter Parsons

Aleksey V Tsingauz

Jason Shaver

William Edwin Hiebert

Jobst-Immo Landwerth

Gen Lu

Ghanashyam Chandrasekhar Namboodiripad

Pranav Krishnamoorthy

Sayed Ibrahim Hashimi

Richard Steele Gibson

Tanner Evan Gooding

Claire Novotny

Dmitry I Lyalin

Damian Paul Edwards

Systems and methods for implementing changes made to source code of a program at runtime are provided. In particular, a computing device may execute the source code in a runtime environment and detect changes made to the source code at runtime in the runtime environment. In response to detecting the changes, the computing device may determine if the changes were made to a type in the source code identified as reloadable. In response to determining that the changes were made to the type in the source code identified as reloadable, the computing device may create a new version of the type and perform implementation of the changes to the source code at runtime using the new version of the type.

Implementing changes made to source code of reloadable types at runtime

Software provenance validation reports whether a validation binary matches the source code, resources, and other parts, as well as the compiler, runtime, operating system, and other context, which is specified in a provenance manifest for a release binary. Part context checksums, software versions, tool parameters, and other aspects of a build are checked. Certification signatures, timestamps, certain version differences, source code locations, and other data may be ignored for validation purposes. A provenance manifest may include other provenance manifests, including binary rewrite manifests. The provenance manifest may be stored in a debugger file with symbol information, or stored separately. Partial matches may be reported, with details of what matches or does not match. After provenance of a binary is validated, the binary's source code can be analyzed for vulnerabilities, thereby enhancing software supply chain security.

Software provenance validation

A change to a first version of source code of an application that is running with a debugger attached is identified, resulting in a second version of the source code. It is determined whether the change occurred with corresponding software suspended or not. The change is applied to the software without restarting the software, based on applying the change using edit and continue (EnC) when the change occurred with the software suspended, or applying the change using hot reload when the change occurred with the software not suspended. Subsequently, the software is suspended, and debug state is presented. The presentation includes presenting the second version of the source code after EnC, or after hot reload and when the software is suspended in an updated memory entity; or presenting the first version of the source code after hot reload and when the software is suspended in a stale memory entity.

Source code editing combining edit and continue with hot reload

Hot reloading a running application with an unsaved source code change. A code change to a source code of a running software application that is associated with a project type is identified. The code change is stored within an in-memory editor buffer, and is uncommitted to any source code file. It is determined that the code change can be applied to the running software application using hot reload. Hot reload agent(s) associated with the project type are identified. Using the hot reload agent(s), the code change is communicated to an application runtime associated with the running software application. At least one process of the running software application invokes a new compiled code entity corresponding to the code change.

Hot reloading a running application with an unsaved source code change

A compiler can instrument a program during the front end of compilation to collect data about runtime behavior when the program is executed. Instrumentation can occur during source language processing rather than later in the compilation chain. The instrumentation can occur in between semantic analysis and code generation. The instrumentation can occur in an instrumenting rewriting phase. The instrumentation can occur in a first lowering phase in which high level constructs in a programming language are rewritten as lower level constructs in intermediate representation (IR). The compiler can inject the instrumentation code at particular points in the source code based on specified language constructs in the source program. The types of instrumentation injected can be extended by providing additional information to the compiler at compilation time, without the need to reprogram the compiler.

Instrumenting program code

Metadata tables can provide the link between the instrumentation information collected and the location in the source code of the programming language construct that was instrumented. The metadata tables enable the relationship between the programming construct in the source code and the dynamic analysis information collected to be exact rather than an estimate. During compilation information is collected that enables a mapping between document table and analysis table to occur.

Mapping dynamic analysis data to source code

Growing community of inventors

Redmond, WA, United States of America

Tomas Matousek