I have a windows form application and i want to make my own custom jumplist. To do this i need to use the namespace System.Windows.Shell but i can't access it, and i can't find a reference for it in the list of references either. I have checked some tutorials but they all use XAML (WPF Application) and some of them just mentions this can be done by coding as well.
So my question is, is it possible to access the namespace needed in a windows form app or do i need to use WPF? And if it is possible then how? And if not, then is there another way to do it in a windows form app?
I'm using Visual Studio 2010 Ultimate (C#).
Thanks in advance!
The System.Windows.Shell namespace is in the PresentationFramework.dll assembly. You can find that out on your own if you search for the namespace, the containing assembly will be displayed in the details.
An assembly reference to PresentationFramework is required. The namespace is only available in .NET 4. Use Project + Properties, verify the Target Framework setting. Using it in a Winforms app is fine, the classes don't require the WPF plumbing to work. They are wrappers for the Vista API extensions.
Related
I am writing an example UWP program, that uses EmguCV (an OpenCV wrapper for programs written in VB, C#, .NET, etc.), to see if I can use it in a UWP app for a project I'm working on. I'm using Visual Studio 2017 Community and EmguCV 3.3.0.2824, which I downloaded the Windows installer and ran it on this Lenovo Thinkpad laptop with Windows 10 Enterprise x64.
For some reason, when I try to build the solution, I get these two compiler errors in this photo.
In plain text:
XamlCompiler error WMC1006: Cannot resolve Assembly or Windows Metadata file 'System.Windows.Forms.dll'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\WindowsXaml\v15.0\8.2\Microsoft.Windows.UI.Xaml.Common.targets(354,5): Xaml Internal Error error WMC9999: Type universe cannot resolve assembly: System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
Why do I have an Assembly conflict between Emgu.CV.UI and the UI namespace in the UWP API? What can I do to enable using both in my app?
This photo is what the Solution Explorer looks like.
In plain text:
I have all the default files Visual Studio 2017 generates when I create a blank UWP application. In addition, I have a file called RTG_Demo_App.dll containing some code written in C++ that uses OpenCV. In the References group, I am referencing Emgu.CV.UI, and Emgu.CV.World.
I am using the default code App.xaml.cs has, as well as MainPage.xaml.cs, with the exception that I have the following lines:
using Emgu.CV;
using Emgu.CV.Structure;
using Emgu.CV.UI;
After doing some research and experimentation, the root cause I found is a conflict between the reference to Emgu.CV.UI (Emgu.CV.UI.dll), and the UI namespace in the library for the UWP. I can't remove the reference to the "Universal Windows" library because it's part of the UWP framework I need for the project.
I did do some research around, except I couldn't come across a resource to where the project involves EmguCV with scripts written in C# directly and to be built for the UWP, rather than Visual C# or .NET.
What I am trying to accomplish here is a project where OpenCV is used, the target is UWP, and the scripts are in C#. OpenCV is not supported by C#, so I'm using EmguCV instead.
Please help me out here.
System.Windows.Forms is not available for UWP projects since it is a wrapper around User & GDI, which are both unavailable for UWP.
You can use a Desktop Bridge project if you only want to ship on Desktop.
I am trying to detect what key is pressed by a user, normally I can use the 'System.Windows.Input' reference, however when I try to reference it, there is no library for it.
Is there something that I am missing or is this just not supported on the Mac version of Visual Studio?
Thanks
Alex
You're right that is not possible (and isn't even logical to be possible).
Visual Studio for Mac is not for developing software for Windows at all and nearly nothing in namespace 'Windows' is available. As I said it shouldn't be even expected - for example in your case keyboards for Windows and Mac are just not 100% same, so even some key enumerations would be purely impossible to port.
Depending on the project type that you use (Mac app, iOS app, Android app, Xamarin forms app) you must find alternative APIs.
No one has ever made one user interface kit to work on another. They are just different. There can be only meta interface like Xamarin forms that brings only common things available everywhere so that they can be translated into every native user interface.
Actually, a big part of System.Windows.Input namespace is located in the WindowsBase.
But it won't help much, since Keyboard class that you're looking for is inside the PresentationCore assembly, which is a part of WPF, that isn't (and, I guess, never will be) supported on Mono.
The only viable (-ish) way to get it is to build from the sources a part of Mono that's never made it to release.
You can use System.Windows.Forms, though.
I recently got to experimenting with the Cloud-Toolkit controls in my Applications i develop for customers, however adding the controls is easy(Simply add the dll) but when building the solution it seems i'm getting a stating i'm missing a namespace reference, what could it be ? The toolkit did not come with any instructions.
Thank you for your time.
I have a WPF dll with a user control. It works just fine when I use it in a WPF project as a reference.
I needed to test in a mixed environment. So I created a Windows Forms solution, added the reference to both the WPF dll and the WindowsFormsIntegration dll. I placed an ElementHost in the form.
In the code behind, I called using on the WPF user control namespace, created an object of the user control and assigned it as the child of the ElementHost. Till this point, intellisense also seemed to work fine. The moment I built the project, however, I got a build error saying that the WPF namespace that I had used was not found.
All dlls are built in .NET 3.5 and the client solution is also in .NET 3.5. Is this a known issue? What could be off with this scenario?
Can you please follow the following link to check whether you have referred all the dll's which is necessary to run WPF custom control in Winform
http://msdn.microsoft.com/en-us/library/ms742215.aspx.
I am new to Windows 8 App Store development and have bumped into something strange.
If I create a normal .net library (signed library) and attempt to add it to my Windows Store application, Visual Studio 2012 moans that I can't add this project. Both projects are in the same solution.
This project contains a reference to the System.Net assembly, as I use some of the types from there. I know that System.Net is not a fully supported namespace. TcpClient, NetworkStream, etc have all been removed. I also know that StreamSocket, DataReader and DataWriter in the Windows.Networking namespace is the alternative.
Before I loose you, let me get to the point. Instead of adding the compiled assembly from this project as a project reference to the Windows Store application, I browse for the compiled assembly on my hard drive and reference the assembly directly.
To my surprise, this worked! This leads me to the following questions:
Why? That doesn't make sense to me. Someone please explain.
Also, if I use this library, will the Windows Store reject my application? Answering the second question myself... Answer is YES! Windows Certification App, no longer recognises this as a Windows Store App if the mentioned library is referenced.
There are a couple ways to add an assembly reference to a project:
Add assembly reference to a project in same solution.
Browse for an assembly somewhere on your hard drive.
In Visual Studio 2012, if you add a non compliant WinRT assembly reference to a WinRT project, Visual Studio 2012 won't allow it.
However, if you add the same assembly to the WinRT project by browsing on your hard drive, the assembly is referenced successfully. This only works if the referenced assembly is signed with a strong key. I'm not sure if this is a flaw in the product or intentional.
Microsoft makes up for this flaw (if it infact is one) later on when passing your Windows Store App through certification. Certification fails because it recognises that an assembly has been referenced in the project which is not appropriate for a Windows App Store product.
So in summary, you can NOT reference WinRT assemblies in your WinRT projects. The drawback with doing this is that your app will fail Windows App Store validation. The advantage with this is if you are not developing a Windows App Store product, you can re-use work you've already done.