Prism: Visual Studio 2015 and InteractionRequestTrigger

[codemonkey1337]

When I open up a WPF project that uses Prism and InteractionRequestTrigger in Visual Studio 2015, I get an design time error saying:

The type 'InteractionRequestTrigger' from assembly 'Prims.Wpf' is built with an older version of the Blend SDK, and is not supported in a Windows Presentation Framework 4 project.

I had this problem with Prism 5.0, and also with the latest release 6.0.1.

Everything works in runtime, but all design time support is lost if you include InteractionRequestTrigger.

This is currently the only thing hindering me from moving up to VS 2015. Do you have any work around for this, I would be greateful. Thanks for a otherwise great framework!

[brianlagunas]

What version of the .NET framework are you using? Prism 5.0 and 6.0 only supports .NET 4.5 and greater. If you download the source code and check, you will see that Prism is built against v4.5 of System.Windows.Interactivity. Have you tried an assembly redirect?

[codemonkey1337]

I'm building against .Net Framework 4.5.2 (On Windows 8.1). Everything works fine with VS 2013. But with VS 2015, I get the design time error stated above. It's very annoying, and completely disables all design time support for my views (that uses InteractionReguestTrigger). I was able to recreate it in a simple project too, that you can download from here: http://filenurse.com/download/ed76267337b258a491159af8d43fcb40.html

I have not tried a assembly redirect, and I'm not sure what I would redirect?

[brianlagunas]

Thanks for the sample. Unfortunately, it worked perfectly for me in VS2015 with no errors or warnings. @briannoyes and @bartlannoeye do you have any issues with this?

[codemonkey1337]

I took me some time, but I finally realized that something must be wrong with my VS 2015 installation. I tried my sample project on a few other computers, and it worked on those. So I dug around the references and other stuff and tried to see if I could find what was missing/broken, but I eventually gave up and reinstalled VS 2015. On voila, now it works. So, the issue must have been with some kind of plugin or other extension to VS 2015 that caused this very bizarre behavior. Sorry to have taken up your time with this, but hopefully it might help someone else having the same problem (there are more, I found a few similar cases when googling).

[brianlagunas]

I'm glad you got it sorted out. Let us know if you run into anything else.

[SamJongenelen]

Me and 2 out of 3 members of our team have the same issue.

<i:Interaction.Triggers>
        <prism:InteractionRequestTrigger SourceObject="{Binding ConfirmActionRequest}">
            <ex:EditorPopupWindowAction IsModal="True" CenterOverAssociatedObject="True" Icon="..\..\Logo.png" ResizeMode="NoResize" />
        </prism:InteractionRequestTrigger>
        <prism:InteractionRequestTrigger SourceObject="{Binding MessageRequest}">
            <ex:EditorPopupWindowAction IsModal="True" CenterOverAssociatedObject="True" Icon="..\..\Logo.png" ResizeMode="NoResize" />
        </prism:InteractionRequestTrigger>
    </i:Interaction.Triggers>

The first time the XAML is opened, the designer displays correctly. Closing and re-opening the view (a usercontrol in my application) kills the designer again.

The following then appears in my VS2015's Error List:

Severity    Code    Description Project File    Line
Error       The type 'EditorPopupWindowAction' from assembly 'Comparn.Program.Editor.Common' is built with an older version of the Blend SDK, and is not supported in a Windows Presentation Framework 4 project.   Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    18
Error       The local property "Actions" can only be applied to types that are derived from "TriggerBase".  Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    14
Error       The type 'InteractionRequestTrigger' from assembly 'Prism.Wpf' is built with an older version of the Blend SDK, and is not supported in a Windows Presentation Framework 4 project. Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    14
Error       The local property "SourceObject" can only be applied to types that are derived from "EventTriggerBase".    Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    14
Error       The type 'EditorPopupWindowAction' from assembly 'Company.Program.Editor.Common' is built with an older version of the Blend SDK, and is not supported in a Windows Presentation Framework 4 project.   Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    15
Error       The local property "Actions" can only be applied to types that are derived from "TriggerBase".  Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    17
Error       The type 'InteractionRequestTrigger' from assembly 'Prism.Wpf' is built with an older version of the Blend SDK, and is not supported in a Windows Presentation Framework 4 project. Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    17
Error       The local property "SourceObject" can only be applied to types that are derived from "EventTriggerBase".    Company.Program.Editor  C:\SOURCES\Company\Company.Program\Company.Program.Editor\Views\Editors\TableEditor.xaml    17

Perhaps this is something that can be fixed in the NuGet package?

[codemonkey1337]

I can add that before reinstalling VS 2015, I downloaded the sources for Prism and recompiled them on my machine, and used those binaries in my project. That made no difference, so I'm quite confident that the problem is outside of the Prism library and more related to the local installation of VS 2015.

After reinstalling VS 2015, I noticed that the dates on the folder "C:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework" had changed (and sub folders), so perhaps it is those files that somehow was not working correctly before reinstalling.

All I know for sure is that reinstalling VS 2015 on my machine solved the problem. Good luck!

[briannoyes]

This appears to be a problem with VS 2015 to me. I had the same thing two days ago but in my app I was not using Prism at all, I got the same error using a DataStateBehavior in the Interaction.Behaviors collection. In my case, some of the time, closing, reopening, cleaning, and rebuilding my project would make it go away for a while. But I was able to run just fine, just broke the designer. And since I rarely use the design surface, I didn't care a whole lot. I found a number of posts on StackOverflow with the same error but other behavior/trigger types substituted.

[codemonkey1337]

I agree Brian, and I can add that on my machine the problem has not reappeared a single time since reinstalling VS 2015.

[briannoyes]

Good to know, thank you. Guess I may have to uninstall/reinstall too. But I think I'll wait until after I am done presenting at DEVIntersection Europe this week. Trying to do it now would be like sacrificing my machine on the alter of the demo gods... what could possibly go wrong? :)

[SamJongenelen]

question; did you fully uninstall/reinstall, or do you recon that 'repair' could work as well?

I'm gonna try copying the VS Blend application files from my colleagues' PC to mine first. :+1:

[codemonkey1337]

Sam, my first inclination was to try "repair". But for some reason that option didn't present itself, so the choice was easy; I had to uninstall/reinstall (it took a few hours, which was a bummer. And you can't even run VS 2013 during this, it won't start as long as the installation is in progress).

[SamJongenelen]

I can confirm a Visual Studio 'repair' did not resolve my issue.

However, copying the contents of c:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework (from working colleague PC) to my PC resolved it!

[brianlagunas]

I'm glad you got it figured out.

[codemonkey1337]

I regretted not trying that before reinstalling! Thanks for the information, now we know what to do when/if this appears again. Or perhaps we should pinpoint the exact files that differs? :-)

[dlurton]

Having the same issue--tried re-installing VS 2015... No dice. Tried replacing the contents of the folder mentioned by SamJongenelen with the contents from a colleage (though I can't be certain if he's having the issue or not because he's not doing any WPF dev currently). No dice. Googled deeply and found this: https://connect.microsoft.com/VisualStudio/feedback/details/755407/xaml-designer-will-not-display-when-using-blend-sdk-behaviors#

It's "closed" but indicates that it's being looked at internally. Wonder if this is the same issue?

[brianlagunas]

Probably the same! Good find. I hope they figure this out soon.

[SamJongenelen]

Good find indeed! Did you ask ms support about this? I feel I might if I have the time for it

[Arnie38]

Hey guys. I've been working with MS support on this one (off and on) since January '2016. It does appear that the MS installer does not properly register/update blend dll versions in the GAC. There is a workaround on that connect site link that suggests re-registering them with the gacutil tool and then everything works. It seemed to work for me. Not sure why re-installing fixes everything if it's the installer that's not doing something quite right.
All I know is that everything worked perfect in VS2013. When I upgraded to VS2015 Update 2 any time a xaml page had an expression blend type in it the designer would break. But re-registering the blend dlls from their latest install dir into the gac seemed to fixed everything.
I believe Microsoft still has a bug on their hands and need to fix it.
If you guys don't mind going to this connect site link to up vote and comment on it that would be great.
In the meantime I continue to work with MS support to read their own connect site submission on this and take ownership :(
https://connect.microsoft.com/VisualStudio/feedback/details/755407/xaml-designer-will-not-display-when-using-blend-sdk-behaviors#

[brianlagunas]

Voted! BY the way, in the next update we will be shipping the assembly with our Prism.Wpf package so that this doesn't happen anymore.

[uckuper]

My apologies folks. This is a key component for WPF, but its implementation is a travesty. I’ve had all sorts of issues as other users have in VS 2015 and in 2013 with these components causing markup errors in XAML. The ViewModelLocator works, but breaks the IDE and so do InteractionRequestTrigger, PopupWindowAction, and it’s just a mess. To make things worse, all the namespaces changed drastically from the previous version and my attempt to upgrade from the limping 4.1 to version 5 wasted 2 days of development. It actually introduced more headaches and the refactoring to the new assemblies was a reminder of the old days of COM DLL Hell. I thought those days were over. But apparently they are alive and well in the Prism library. Forgive me for being so negative, but this component has been one of the greatest headaches and disappointments in my 14 years of .NET. Its only saving grace as far as I can tell is Commands and BindableBase. The rest is just one problem after the next. Even the sample code comes up with the same errors. I understand some folks have had no problems with it. But the big issue here is the lack of consideration for backward compatibility such that these problems would not happen when the assemblies are used in systems with various configurations. In version 6, please consolidate all assemblies into fewer ones. It is not nice to have to have 4 separate xmlns declarations in your XAML to make this work.

[brianlagunas]

While I appreciate your open and honest feedback, I think a lot of it is misplaced and you are not fully informed of the current state of Prism.

First off, the version of Prism you are talking about (v4.1 and 5) was built and maintained by Microsoft and as not maintained by the community here on GitHub. The breaking of VS was not an issue with Prism, but rather bugs in Visual Studio. Obviously if a UserControl implementing an interface breaks the VS designer, that is not Prism's fault. Your blame is misplaced.

The issues with the Interactivity are annoying, but once again it's not a Prism issue. Prism did not write or ship the Interactivity assembly. It used to ship with Blend, then Blend for Visual Studio. Depending on what version of VS/Blend and VS update version you installed you might have a different interactivity version that was only because of a timestamp. This is nothing Prism caused. Once again, your blame is misplaced.

Yes, you are correct. Microsoft really made a mess of the references. That I can agree with. If you were using NuGet, changing those references wouldn't be such a big deal. But, if you didn't then it as definitely a pain in the ass to manually replace all the references. Luckily, Prism 6 already fixed this issue. There are only 3 references now; Prism.dll, Prism.Wpf.dll, Prism.Unity.Wpf.dll.

Backwards compatibility is always a consideration. We have decided not to make a number of changes/improvements as to keep backward compatibility in tact. Having said that, somethings must change and evolve to improve the framework. Sometimes those require a breaking change. These changes are documented, and as a dev considering an upgrade you must read those docs so you can decide whether you want to upgrade or not. If you decide to upgrade based on your research, then you must also have a plan in place to have a successful upgrade.

If you would have taken the time to review the wiki, project readme, updated docs, and changes you would have seen that all of these complaints have been fixed. Once Prism was given to the community, a number of changes were made to address all of these issues. Parts of Prism were architected to get around the bugs in Visual Studio so you no longer get those errors. References were simplified. xmlns namespaces simplified to one. New NuGet packages created.

Prism 6 was initially released with these fixes in Oct of last year.

[uckuper]

Brian. I sincerely thank you very much for your clarification.Please don't take it personal. I appreciate the efforts of those that contributed to this project. Obviously I am frustrated with this. I am inclined to accept that I am misinformed, but part of the issue is that it is hard to determine which is the right Prism to use. If I go to Package Manager and type in Prism, a very large list of components come up. Which is the "right" one? When this question comes up, I will usually go for the official Microsoft or Patterns and Practices version, which is what I did. And I will say this in my defense. I downloaded the source code to see if I could more easily navigate through the mechanisms at play, and in my environment, the project generates 33 warnings, some of which are inconsequential, but there are lots that warn about the use of obsolete classes. So this gave me a bad feeling about the state of this component. The samples provided also break the designer in my VS 2015 Update 2.

Breaking the designer is definitely its worst offense. I have a project I started a few years back, and from the initial stage, Prism was causing problems on the designer on VS 2012 and then VS 2013. I just got an opportunity to continue on this project, which has been dormant for a while, and things just got worse. Here we are years later and the newer versions of VS 2015 and Prism still can't play nice.

Forgive me for getting verbose, but as a point of reference for the contributors of this project, I recently for the first time had to take a peek at iOS development environment on a Mac, even though I have been strictly a Microsoft developer and defender, mostly because of the superiority of C# as a language (compared to Objective C), solid performance and .NET's powerful libraries. But I am noticing that in XCode it is stupidly easy to hook up the equivalent of Commands, Interactions, View-Model wire-up, and so forth. It is build in. You don't even have to look at a single line of XML. It's all done through dragging gestures, property pages and IDE functions that correct inconsistencies just by clicking a button. And much to my disappointment, on the MS side, Prism requires all sorts of careful cajoling to get things to work, and then again you have to trust the XAML because the designer stops working.

In summary, I would hope this project gets to a point where it is closer to what Apple has achieved, and you can use a more graphical approach (as in Blend or XCode) to build an MVVM architecture. Even if the graphical approach cannot be achieved 100%, I would hope this stuff would just work in the designer. I don't know what the relationship is between Microsoft and the community that has taken over this project, but I would hope there is some way to stop pointing fingers and get Microsoft to respond to the issues and work with the community to get such an important component to work harmoniously with the IDE. It is sad that Microsoft has dedicated such thin support to desktop app development. They have built a great mechanism for MVC in ASP.NET, which I have used repeatedly, but they have abandoned WPF when it comes to MVC or MVVM.

Can you please advise as to what is the best approach for my project? Do you think I would have to spend another couple of days fixing things if I update to version 6 from this group's library?

Thank you and sorry for the negativity. WPF is a great platform, and Prism is the missing link to make it awesome. It is now somewhat broken, and therefore the frustration.

[brianlagunas]

Which is the "right" one? When this question comes up, I will usually go for the official Microsoft or Patterns and Practices version, which is what I did

Well when you added the "official" MS packages you should have seen the word Deprecated next to the package title, with instructions on what to use in the description. You should have also started by reading the Readme of this project which tells you exactly which Nuget packages to use. It also tells you the history of Prism and how it ended up on GitHub and who maintains it now. It also points you to some training videos to help you better understand Prism. There is also a ton of documentation available that helps you better understand various topics.

Breaking the designer is definitely its worst offense

Once again, your frustrations are misplaced. All of the designer issues you describe are not the fault of Prism, but rather Visual Studio. We had to implement work-arounds in Prism just to get VS to work properly.

I just got an opportunity to continue on this project, which has been dormant for a while, and things just got worse

I am actually curious as to what in VS you think is broken due to Prism. There are only two known issues. One regarding ViewModelLocator and the use of IView, and then the issue with Microsoft's Interactivity assembly. Having said "things just got worse", you are just being dramatic now. Nothing related to the Visual Studio designer changed, so it couldn't have gotten worse. If you upgrade to Prism 6 it even gets 100% better, because these have been fixed.

Here we are years later and the newer versions of VS 2015 and Prism still can't play nice.

Once again, you are wrong. There are no issues with Prism 6 and breaking the Visual Studio designer now.

Forgive me for getting verbose, but as a point of reference for the contributors of this project, I recently for the first time had to take a peek at iOS development environment on a Mac, even though I have been strictly a Microsoft developer and defender

This has nothing to do with Prism, so I fail to see the relevance.

Prism requires all sorts of careful cajoling to get things to work

Could you please elaborate on all the cajoling you need to do in order to get it to work. I feel you are exaggerating your frustration to the point of trying to make Prism look as if it doesn't work.

I would hope this project gets to a point where it is closer to what Apple has achieved

You do realize you are comparing apples to oranges here right? Prism is an application framework for WPF, UWP, and Xamarin.Forms. It has nothing to do with the underlying platforms it supports.

I don't know what the relationship is between Microsoft and the community that has taken over this project, but I would hope there is some way to stop pointing fingers and get Microsoft to respond to the issues and work with the community to get such an important component to work harmoniously with the IDE.

There is no relationship with MS. This community has no association with Microsoft. There is only person here I see pointing fingers. Once this community took this project over, every Visual Studio designer issue you have complained about (though you haven't been very explicit about which ones exactly) has been fixed.

Can you please advise as to what is the best approach for my project? Do you think I would have to spend another couple of days fixing things if I update to version 6 from this group's library?

This is only a choice you can make. Given your history you have given me, I would say that it would take you a couple of days to upgrade to Prism 6.

It is now somewhat broken, and therefore the frustration.

I want you to realize you are complaining about an old version of a framework, and it's samples, that is no longer supported by Microsoft and hasn't been for over a year.

[brianlagunas]

I want to also mention, that prism is now open source and supported by the community. This includes you. Since you have already identified a number of areas where Prism is broken, I think you are the perfect person to help us fix it. If you would please fork Prism and fix the issues you have discovered. You can then submit a PR with the fixes so that the entire Prism community can benefit. You can help make Prism better, which is the whole point of moving Prism to GitHub. Just make sure you follow our contributing process:

https://github.com/PrismLibrary/Prism/blob/master/.github/CONTRIBUTING.md

[uckuper]

Hey Brian. I accept your criticism. Like I said, it comes from my frustration. You are right, the two things you mentioned are the ones I considered "broken". Interactivity and ViewModelLocator.

I would only like to clarify my statements about the iOS development environment if I may because I think it does have relevance in the sense that it could be a good model for further work on Prism. The iOS IDE for generating iOS apps is based also on an MVVM model. I believe they label it MVC. All the functions that Prism brings to the table are integrated into the XCode IDE. Every view has a view-model that serves as the controller, so it's very similar. They also support dependency injection through a model binder, as well as the equivalents of commands, interactions, etc. The difference is how well integrated it is with the IDE. You connect commands by clicking and dragging from the visual control in the designer that should bind to the command, into the view-model source code page. This action automatically generates the necessary code in the view-model to support the command. To do interactions you do something similar by clicking and dragging. Data binding also works this way. You drag from the visual component into the source to create a binding to a property that supports a property_changed event like BindableBase. I know Prism does not deal with the graphical design part, but it would be nice to aim for this in the future.

Regarding your invitation to contribute, thank you and it will be my pleasure if I can integrate that into my current project that needs to take high priority. If I find anything wrong that I can fix, I will certainly help out. In the meantime I will try Prism 6, and I thank you very much for your prompt responses and suggestions. Sorry for the rant. I really do appreciate your support.

Carl

[dansiegel]

@uckuper again as Brian said before you're comparing apples and oranges. You cannot compare an Application Framework like Prism to xCode and iOS. It's about the same as comparing Monkey's and Rocks. Keep in mind Xamarin with millions in funding is only in the very early stages of testing any kind of live XAML previewing, particularly since they support multiple platforms which change how that XAML will render. Before anyone in the community on their own or as a coordinated effort can ensure that Prism works with a WYSIWYG type editor there has to be one first. I have no doubt that as the tools become generally available in Visual Studio and Xamarin Studio you will start to see support for graphical editors on Prism projects. Now I realize that there may be some applications right now in which Xaml previewing works until you add Prism. If that's the case by all means open a new issue. The great part of this being a community driven project is that someone else may just say that's a great idea and spend some time to take care of it.

[uckuper]

@dansiegel We are not in disagreement. I understand that Prism is an application framework and XCode is a development environment and iOS is an OS. Apples and fruit-baskets. Oranges would be too similar.

I am simply suggesting it wold be nice to have some integration with the Visual Studio IDE via a VS extension that would auto-generate the necessary XAML and model code for you through user interaction with the Visual Studio's WYSIWYG editor (which does work when the XAML markup does not throw errors). In the earlier days of Visual Studio there was always an attempt made to provide design-time functionality to components. This extension would use Prism as the MVVM framework and allow for automatic code generation to wire-up triggers with commands, interactions and navigation via user interaction with the VS design-time environment in a graphical way.

This would simplify all the knowledge required to create MVVM applications with Prism. The learning curve would be easier to overcome.

I offered the XCode IDE as an nice example of how the extension might work. It uses its own Prism-like framework in the background while the IDE generates the XML code and model code for you as you design your views, wire up triggers and write the logic in the model/controller. All done graphically. I understand it is beyond the scope of the current project. (But it would be very nice.)

[uckuper]

Hi Brian. I did the upgrade to Prism 6.1.0. It was not as painful as before. Had it done in a couple of hours. Of course this time I knew what packages to use and what to look for, and thank you for consolidating those namespaces into fewer assemblies. That made a lot of difference. Thanks again.

[Enhakiel]

A quicker way to solve it, rather than reinstall visual studio :
gacutil -i "C:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework\v4.5\Libraries\System.Windows.Interactivity.dll"

[brianlagunas]

Great tip!

[Arnie38]

+1 for Enhakiel's comment. It was something I was suggesting in my earlier post. I can confirm if you just GAC the expression dlls everything works fine. The VS designer must be looking for the GAC version of them; without it the designer gets confused. I'm still not sure why re-installing VS would fix things unless they updated the install to appropriately install/GAC the version 4.5 of Expression runtime.

[typescripter]

+1 for Enhakiel's comment. This worked for me also. Thank you.

[alewis-github]

Just thought I'd add a comment here as I came across this thread searching for solutions to the same error message, even though I'm not using Prism and I'm using VS2017.

The problem began after downgrading my WPF project from .Net 4.6.2 to .Net 4.6.1 (because most of the users had 4.6.1 installed and the Admin install of 4.6.2 was getting tedious).

The rebuild/redistribution was fine, but as soon as I came to make a change in one of the code-behind files, everything broke with these weird "local property X can only be applied to types that are derived from Y". Which is odd since what's happening in every case is the xaml is instantiating a Type Y, so where else is it deriving anything from?

I'm still stuck, but the issue is certainly not confined to Prism.

Ade

[codemonkey1337]

Enhakiel's comment has a slightly miss-spelled path: The correct command is:

gacutil -i "C:\Program Files (x86)\Microsoft SDKs\Expression\Blend\.NETFramework\v4.5\Libraries\System.Windows.Interactivity.dll"

And that actually just worked on my current computer running the latest prism libraries and VS 2017.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.