0 Comments

Attach to dotnet.exe extension for Visual Studio 2017 & 2019 now has a new version 1.0.0.1. As the version number indicates, only a small thing has changed: The extension manifest had problems with its dependencies, causing issues when trying to install the extension to VS 2019 Preview.

The new version is now available for download from the project’s repository: https://github.com/mikoskinen/AttachToDotnet/tree/master/releases/1.0.0.1

Unfortunately the extension is still not available through the Visual Studio’s extension marketplace, but I hope to have it there in the following week.

Background

Just a quick recap and reasoning for the extension: There’s usually many dotnet.exe processes. Attaching Visual Studio’s debugger to the correct one can be hard. This extensions aims to solve the issue by displaying the actual .DLL of the dotnet.exe process.

0 Comments

I’ve released a new open source extension for Visual Studio 2017&2019 which aims to make it easier to attach and to reattach the Visual Studio debugger to the correct dotnet.exe process:

With the default “Attach to process” –feature in Visual Studio it’s often hard to know what is the correct dotnet.exe to debug. Without the extension the visibility to dotnet.exe process is often this:

The extension aims to solve this issue by parsing the actual application from the process’ command line. In addition to displaying and attaching to a particular project, the extension provides “Reattach to dotnet.exe” command. This functionality works even if the process id changes (as it does when using dotnet watch).

Default shortcuts: 

  • Reattach: CTRL + Shift + Del
  • Attach: Shift + Del

Note: For now the extension has been mainly tested with ASP.NET Core 2.0 based applications. Later versions of ASP.NET Core and .NET Core may change things so it’s possible that the extension displays these processes incorrectly.

The extension is not yetavailable from Visual Studio Marketplace but I hope to see it there shortly. But you can download and install it from here: https://github.com/mikoskinen/AttachToDotnet/tree/master/releases/1.0.0.0

The source code for the extension is available through Github: https://github.com/mikoskinen/AttachToDotnet

Your Razor Components can implement interfaces even if you’re not using code-behind files. Given that a basic components looks like the following:

@page "/"

<h1>Hello, world!</h1>

Welcome to your new app.

@functions {

}

It’s not directly obvious how the implementation happens. But for that, we have the “@implements” directive:

@page "/"
@implements IMainPage

We can do the actual implementation in the functions-block:

@functions {
    public void UpdateText()
    {
        // Implementation logic
    }
}

Here’s a full example:

@page "/"
@implements IMainPage

<h1>Hello, world!</h1>

Welcome to your new app.

@functions {
    public void UpdateText()
    {
        // Implementation logic
    }
}

In some child & parent component situations it would be good if you could render or at least get an access to an instance of a Razor Component.

Given the following scenario where we try to render an instance of the Counter-component inside the Index-component:

<h1>Hello, world!</h1>

Welcome to your new app.

@counterInstance

@functions{
    Counter counterInstance = new Counter();
}

The following doesn’t work as it only draws the type name of the component:

image

There are couple options around this.

Capturing reference

In many (if not most?) cases you should let Razor Components to take care of creating the instance of your component and then use the “ref” keyword to capture the rendered instance:

<h1>Hello, world!</h1>

Welcome to your new app.

@DrawCounter()

@functions{

    private Counter _myCounter = null;

    RenderFragment DrawCounter()
    {
        return new RenderFragment(builder =>
        {
            builder.OpenComponent<Counter>(0);
            builder.AddComponentReferenceCapture(1, inst => { _myCounter = (Counter)inst; });
            builder.CloseComponent();
        });
    }

Reflection

If you really want, you can access the RenderFragment of the instance using reflection and then draw that:

Welcome to your new app.

@RenderContent(counterInstance)

@functions{
    Counter counterInstance = new Counter();

    RenderFragment RenderContent(ComponentBase instance)
    {
        var fragmentField = GetPrivateField(instance.GetType(), "_renderFragment");

        var value = (RenderFragment)fragmentField.GetValue(instance);

        return value;
    }

    //https://stackoverflow.com/a/48551735/66988
    private static FieldInfo GetPrivateField(Type t, String name)
    {
        const BindingFlags bf = BindingFlags.Instance |
                                BindingFlags.NonPublic |
                                BindingFlags.DeclaredOnly;

        FieldInfo fi;
        while ((fi = t.GetField(name, bf)) == null && (t = t.BaseType) != null) ;

        return fi;
    }

0 Comments

ASP.NET Core ViewComponents usually come in pairs: There’s the class which inherits ViewComponent and there’s the Razor view which is returned by the class:

image

In most of the situations the ViewComponent runs some logic and then returns the view:

    public class MyTest : ViewComponent
    {
        public Task<IViewComponentResult> InvokeAsync(string content)
        {
            return Task.FromResult<IViewComponentResult>(View("Default"));
        }
    }

But what if you need to return the view only in some cases based on the ViewComponent’s parameters or because of some other validation? In these situation you can skip returning the view by returning empty content instead:

    public class MyTest : ViewComponent
    {
        public Task<IViewComponentResult> InvokeAsync(string content)
        {

            if (string.IsNullOrWhiteSpace(content))
            {
                return Task.FromResult<IViewComponentResult>(Content(string.Empty));
            }

            return Task.FromResult<IViewComponentResult>(View("Default", content));
        }
    }