New Rhino 8 C# Plug-in does not Display WPF Window

Rhino Developer
1

Hi,

I have a funny problem that suddenly appeared, because I assume there were some changes in the Rhino Extension for Visual Studio that were not there before.

I created a brand new Rhino 8 C# Plugin and checked “Use WPF”. I then simply created a new WPF Window and Visual Studio will not display it.

image
image730×318 8.6 KB

An interesting addition is that if I don’t go to Build, but add a window first, then it will display it…but the moment I do Build I get this Exception. (If I do Build before creating the Window, I also get the Exception…so Build is the problem)

I checked the .csproj file and realized it looks slightly different than it did until recently. It used to look something like this:

 <PropertyGroup>
    <TargetFrameworks>net7.0-windows;</TargetFrameworks>
    <Version>1.0</Version>
    <Title>MyPlugin</Title>
    <Description>Description</Description>
    <TargetExt>.rhp</TargetExt>
    <UseWpf>true</UseWpf>
    <UseWindowsForms>true</UseWindowsForms>
  </PropertyGroup>

<PropertyGroup>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>

It also did not have this “-windows” in the TargetFrameworks, I had to add it manually. Now, when I created the plug-in and checked the csproj file it looks like this:

  <PropertyGroup>
    <!-- Select the framework(s) you wish to target.
        Rhino 6: net45
        Rhino 7: net48
        Rhino 8 Windows: net48, net7.0, net7.0-windows, net7.0-windows10.0.22000.0, etc
        Rhino 8 Mac: net7.0, net7.0-macos, net7.0-macos12.0, etc
    -->
    <TargetFrameworks>net7.0-windows;net48</TargetFrameworks>
    <EnableDynamicLoading>true</EnableDynamicLoading>
    <TargetExt>.rhp</TargetExt>
    <NoWarn>NU1701</NoWarn>
    <EnableWindowsTargeting>true</EnableWindowsTargeting>
  </PropertyGroup>
  
  <PropertyGroup>
    <!-- Specifies information for Assembly and Yak -->
    <Version>1.0</Version>
    <Title>MyPlugin</Title>
    <Company>MyPluginAuthors</Company>
    <Description>Description of MyPlugin</Description>
  </PropertyGroup>

There are some obvious updates…so that we do not have to add that"-windows" manually and do not have to look at those NU701 warning…but I think the problem is also somewhere there…

It should be simple to reproduce…I did this on two separate computers and I got the same result.

Any ideas? Is this related to some new changes? I create new Plugins fairly often and they are always using WPF, but this is the first time this has happened, and it is a pretty large problem.

Exit code: 80008089 apparently has to do something with frameworks… I also tried removing the net48 framework but it was the same. I also tried including WindowsForms AND Wpf, but with the same result

SOLUTION: I did find one solution, but it is a “hack”, so I still wanted to make you aware of the problem. I simply replaced the PropertyGroups in the csproj file, and made it look like it did in the old plugin versions…this did the trick. I guess I could change line by line to pinpoint exactly where the problem might be, but I did not do that yet…

Thanks
Milos

2

I am using the method of loading WinForms in RunCommand, which I believe is the simplest way.

private static Windows_Form1 Sub_Form = null;

protected override Result RunCommand(RhinoDoc doc, RunMode mode)
{
    if (Sub_Form == null || Sub_Form.IsDisposed)
    {
        Sub_Form = new Windows_Form1();
        Sub_Form.TopMost = true;
        Sub_Form.Show();
        Sub_Form.StartPosition = FormStartPosition.CenterScreen;//居中显示
    }
    else
    {
        Sub_Form.Activate(); //如果已经打开过就让其获得焦点  
        Sub_Form.WindowState = FormWindowState.Normal;//使Form恢复正常窗体大小
        Sub_Form.StartPosition = FormStartPosition.CenterScreen;//居中显示
    }
    return Result.Success;
}
3

Hi @dimcic,

Does changing this,

<TargetExt>.rhp</TargetExt>

to this,

<TargetExt>.dll</TargetExt>

help?

– Dale

1 Like
4

Hi @dale ,

a short test says yes…I created a new project, changed rhp do dll, added a WPF Window, did the Build and the Window was still displayed…so it works.

What does that tell you? And does it mean that we should continue working with the DLL?

Thanks.
Greetings,
Milos

1 Like
5

@dimcic - it’s a Visual Studio issue. While you’re working in your UI, just keep the target extension as .DLL.

– Dale

1 Like
6

This may be helpful.

How to Debug Xaml Designer in Visual Studio

To diagnose issues with Visual Studios Xaml Designer, you should launch a second instance of Visual Studio.

Then kill all WPFSurface.exe processes that are running. Then in your second instance of VS, make sure you open the same solution.

So you now have 2 VS instances, both with the same code open, and no designers running. Choose one of the VS instances and reload the crashed Xaml Designer.

Then switch to the second VS, and press CTRL+ALT+P to attach to process. Find the WPFSurface.exe and attach to that process.

Now all you need to do is reload the first crashed Xaml Designer, and quickly switch to VS2 and hit SHIFT+ALT+P to reconnect.

You should not receive the Exception which was crashing out the Designer Process from the first VS instance.

This is very helpful in diagnosing any issues you have showing UI in the Designer Process. For instance, you CANNOT reference any Rhino functions from within your ViewModel, and then try seeing the View in Xaml.

VS actually runs your VM code to activate the Bindings in your Xaml. I use this process to diagnose issues with why the Xaml Designer is crashing.