In my VSTO application-level word addin, I'm trying to add a Grid to a UserControl in order to make its layout coherent.
However, when I try to declare the grid, Visual Studio complains that the type or namespace "Grid" cannot be found. I solved this error by adding the PresentationFramework assembly as a project reference and importing System.Windows.Controls, but now I have an even bigger issue: Visual Studio complains that "UserControl" is an ambiguous reference between "System.Windows.Controls.UserControl" and "System.Windows.Forms.UserControl".
I checked the top of my .cs file and found it already was importing System.Windows.Forms by default and now, it is also importing System.Windows.Controls.
I'm wondering why the VSTO project defaulted to importing System.Windows.Forms in the first place instead of System.Windows.Controls and what the main difference is between the two namespaces because in my WPF application I use System.Windows.Controls. Thank you!
From origin VSTO was a Forms based set of tooling, and XAML based UI option is only from later years. Obviously you still can use System.Windows.Forms and reference that in your XAML applications so when adding the XAML References there are some ambiguous items if both present (I always tend to run into the XAML and Forms MessageBox ambiguity interfaces) and you need to prefix the ambiguous items.
What I do is trying to be either full on the XAML side or decide to move to the Forms side.
Probably the VSTO, a somewhat older technology by now, project templating is based on the Forms libs to start with but you are free to move completely into the XAML world. My own solutions today are fully XAML based, but I fall back to Forms every now and then (doing a quick demo for instance).
So it is just a technology choice and VSTO is going back a long time so it started with Forms. Go with the new and shiny XAML technology if you like (I'm biased, I love that technology) or stick to the Forms technology. You can use them both.
Related
So when I create and do what ever I like to do with a winforms project on my Win10 PC, all the forms in that project have that kind of Metro Style UI design.
However if I create a dll project on the same PC, and reference to what I think is the same System.Windows.Forms dll as the winforms projects do, the forms I can create from the dll look a little bit as if I was on Win7 and had enabled the use XpVisualStyles option.
i.e.: As an basic example: all buttons on the form are set to a 3d border style by default and trying to get them to be flat is not that easy (if they should look good atleast)
Question is: Why do the forms created from the dll look differend than the ones created from a winforms application, althought they both reference the same dll (System.Windows.Forms I even checked hash and version)?
2nd Part how can I get the forms created from the dll to look like the ones from an winforms project?
Additional Information: The dll forms have been created by referencing the dll from 1 a console project and 2 an other winforms project. Both looked like Xp.
So thanks to the nice comment by #Reza Aghaei this question is solved.
1st Solution
Make sure that in the Application that opens the form the Appliction.EnableVisualStyles(); is called, this requires a reference to System.Windows.Forms if there is none.
The shown form will then look just like it shows you in the designer that it will.
2nd Solution
Call the Appliction.EnableVisualStyles(); inside the dll that owns the form.
This be done by
Calling in the constructor of each form
Or via some static function in the dll that takes care of all initialization
additionally there could be a conditional inside the form constructor that calls some function of the same dll that checks if styles are enabled and if not does so.
I would based on my knowledge commend to use a static initialization function.
I've found a nice VB.NET Theme online, however, my application was C#, so I did the most logical thing, which is creating a new VB.NET Class Library, using the theme class, and then using the DLL through my toolbox's items.
This is the theme's code: http://pastebin.com/bxM7wtyN.
Note that the classes were not set to public, but I did so, as I thought that's why the error popped up. This is the error I'm getting.
Why's that, exactly? I think everything looks fine, and the theme's code works for everyone as they're using VB.NET, but not for me.
Uh, You have 2 ways. Find a c# version or try to convert into c# from vb.net.
Try adding the code to a blank file in your project, and then build the project but don't run it. Now in Visual Studio, open the Toolbox and the new controls should be at the top.
I am learning how to create a Class Library (Windows Store apps) and used a UserControl template to add a user control to it.
Then I added a Grid tag to accompanying XAML. However, the tag is underlined with blue squiggles and when I hover over the tag there is
Grid is not supported in a Windows Presentation Foundation (WPF) project
tooltip shows up.
The library seems to build without errors. I've added the library to an application and use the control in its code. The application is also builds just fine. However, when I run the application I get XamlParseException exception.
I am using Visual Studio 2012 RTM. Both the library and the application reference only two standard assemblies (.NET for Windows Store apps and Windows).
What I might done wrong and how should I fix the library?
In my case I switched from Debug to Release, and then back, and the error was gone.
Go to "Build > Configuration Manager..." and Make a new platform for x86 for all your projects.
It doesn't have to be the active one, you can leave that as Any CPU.
Hope it works as for mine...
I've recently had the same error and found the following in the output window:
10>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFX.targets(268,9): error MC6000: Project file must include the .NET Framework assembly 'WindowsBase, PresentationCore, PresentationFramework' in the reference list.
The solution for me was to add the missing references to my project.
For me it helped to set the "Target framework" in application-properties to .NET 4.0
This appears to be a bit of a "catch-all" for a number of XAML resource errors. I've found two causes so far:
Declaring a Resource outside of the appropriate context- e.g. directly in a UserControl tags, not UserControl.Resources.
Forgetting to include the correct namespace for the "unsupported" class. Example in a basic ResourceDictionary, with no sys namespace defined:
<ResourceDictionary>
<sys:string>I'm not supported</sys:string>
</ResourceDictionary>
I was able to solve my similar issue of..
UserControl is not supported in a Windows Presentation Foundation (WPF) project
.. by removing the PresentationFramework reference and re-adding it via nuget.
[Reposting comment as answer]
I was able to complete the steps with no issues, and it appears you were able to as well. Perhaps there was some other inadvertent modification/setting that was made?
This is xaml getting itself confused. I have the error on one project and not on another. Have a look at the top of the xaml before the grid error and see if there are any references to other controls. Try making a modification that will cause and error and rebuilding one of those controls. Then put it back the way it was to get a succesful build and see if this makes the grid error go away. (it did for me)
Much Like Felix D.s answer, I found from the .csproj file a reference was removed.
Obviously replace the 3 with your needed framework, or use the project properties to set the version ( i think that adds this reference )
Evil Dog Pie was step 1 for me, as some other issues came up. There is always a heap of information in the output log
<Reference Include="PresentationFramework">
<RequiredTargetFramework>3.0</RequiredTargetFramework>
</Reference>
This problem is due to the low version of .NET that you have chosen in your project.
To solve the problem, select the Project from the up menu and then select your Project Properties and from the part of Target Framework select higher version of .NET Framework!
I hope your problem is solved.
Yours sincerely
I built a class library exporting two custom controls using c#. This class library depends on some references, which are duly copied into the bin\Debug directory on build (of a solution using the custom controls) as long as I add only the controls DLL as reference. So far, so good.
If I now add the controls from that output directory into the toolbox and place one on an empty form in the designer, visual studio crashes. If I debug from the custom control solution like so http://msdn.microsoft.com/en-us/library/5ytx0z24(VS.80).aspx, I can see the IO exception that one of the referenced DLLs cannot be found.
So, is there a reasonably elegant way of placing the dependencies for the designer to find them? I tried fiddling with the reference paths in the project settings, but to no avail. I would prefer to avoid setting system-wide paths and installing/registering the control every time I change a bit of code.
Why don't you just reference the project as a whole rather than manually copying in the dll? If you have a good reason for this then fine, but it seems as though you are asking a question which doesn't need to be asked! :P
Hey! I was looking at a cool layout example in particular the V3FluidLayout.xaml found inside this set of examples : http://gallery.expression.microsoft.com/en-us/DynamicLayoutTrans
Anyhow - this appears to be a silverlight app - it runs within a browser. I am trying to pull the V3FluidLayout example into a WPF app - and struggling.
I "add an existing item" pulling the .xaml file into my project. When it goes to compile it, the following errors are found :
Are these artifacts Silverlight? The following is the xaml code within the V3FluidLayout.xaml file
http://pastebin.com/h9ujUax6
Can anybody help me pin why this is not working - and how I can convert that xaml code to work inside my wpf app.
Thanks
Andy
Basically (and from only a quick glance), you'll need a reference to the WPF versions of System.Windows.Interactivity and Microsoft.Expression.Interactions - they are part of Blend. Actually look at the references of that project and find the exact same references, only for WPF.
It looks like they contain pretty much the same classes for both WPF and Silverlight, so I think it should work in the end.
Add references to the interactivity assemblies found here:
C:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework\v4.0\Libraries
You need to install the Blend SDK to get them, the come with Blend also.