When opening a XAML file in VS2010 Professional, the studio becomes unresponsive for 5-7 seconds and many local controls are marked with error bars, since they do not support design time usage. This also happens after a debugged application is terminated.
I've got a i5 CPU, 16GB RAM and an SSD, so I don't think my H/W specs are at fault.
I'm already opening documents in full XAML view (as suggested here) and I've closed all clutterboxes (Toolbar, Document Outline, Data Source) to no avail.
Currently I'm using the XML editor for my sanity, but of course this also means no IntelliSense at all.
Is there a way to completely disable the WPF Designer in Visual Studio 2010 without loosing XAML IntelliSense capabilities?
I don't know if there is a way to use a lightweight XML editor that preserves IntelliSense inside Visual Studio. However I suggest you to try kaxaml.
From the website:
Kaxaml is designed to be "notepad for XAML." It's supposed to be simple and lightweight and make it easy to just try something out. It also has some basic support for intellisense and some fun plugins (including one for snippets, one for cleaning up your XAML and for rendering your XAML to an image).
I had the same problem with WPF XAML. The only way I found so far is to use XML editor. Yes, you will not have IntelliSense anymore but there is no better way here. Using external editors like Kaxaml helps only for primitive XAML files which do not use anything from other XAMLs (Kaxaml doesn't support projects or at least didn't supported them, so it is not useful for real projects). You can also try using Expression Blend for editing XAML files but it is also not that good alternative.
Please add
if (DesignerProperties.GetIsInDesignMode(this))
return;
to Constructor, OnApplyTemplate and Loaded event handler, that will ignore all design time processing and make the controls load faster.
Related
I have a WPF application which is giving me a very very annoying error
System.Runtime.Remoting.RemotingException
[12068] Designer process terminated unexpectedly!
The number between [] changes each time
The XAML is very simple
<UserControl x:Class="STC.Reports.ReportGenerator.Views.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</UserControl>
This has wasted me hours and hours
Does anyone know anything that could help?
I cant get any more information than that above
Even though I have told VS to break on these Exceptions it doesnt
I have also tried to attach another VS and that makes no difference
I have repaired my installation of VS (2012 Professional)
I have also updated to Update 3
This is even happening when I create a brand new WPF application
Everything seems fine initially, then VS just hangs and the remoting error occurs
Paul
What kind of message are You getting?
If it is a Messagebox when You try to use designer - it is a known issue since VS2010 as far as I remember. It is frequently caused by a video card or its driver, so the easiest way is trying to update your video driver or use some older version. Sometimes that help.
The other way is not to use built-in designer. As for me, I wite pure xaml and it seems to be more convenient and faster way of development. Or, if You like visual UI - You may use Blend. AFAIK it is a part of VS2012 now.
I had this error occur for all windows/controls in a project, even if they were brand new empty windows. I had a markup extension causing a design-time exception (with no indication of this from Visual Studio) and I would get this designer error if I used the markup extension in any project resource dictionaries.
Old post but might be useful for future developers who run into this kind of problem.
I had this exact behaviour. Turned out to be a problem related to my viewmodel. At runtime everything works, but at design time VS will try to load the viewmodel standalone and things got haywire. My viewmodel depended on some global object which I created elsewhere at application startup. Loading the viewmodel standalone creates a exception since the global object was missing.
Quite easy to detect actualy. Just test your viewmodel by instantiating it yourself from code. If it fails VS won't be able to run the designer as well and as you see VS unfortunately won't tell you what happened.
I'm new to the Windows world, and I think I'm getting lost in the weeds on a problem. I'd love some advice from people with experience with C++/CLI and WPF and XAML.
I have some win32 code, and I need to run a WPF GUI. I found this MS walkthrough sample, which uses C++/CLI. I adapted it to my purposes, and it works great.
Next, I wanted to rip out the programmatic WPF stuff and use XAML instead. This is so I can hand off the XAML to a designer person and take myself out of the UI design loop, where I most assuredly don't belong. After reading the "WPF Interoperation Projects" section of WPF and Win32 Interoperation on MSDN, I decided to go with the XamlReader::Load option and load uncompiled XAML at runtime. My XAML markup is a Canvas UIElement which I programmatically add as a child of my root Grid C++/CLI element. This works great.
Now I want to add event handler to controls in the XAML. This is where I have started to run into trouble. I'm sure that my general ignorance of the Windows world is 95% of what's killing me here.
I started with Rob Relyea's page outlining the various XAML-and-event-handler options.
I decided to try compiling the XAML as a C# DLL. It's basically the same XAML as what I used in the runtime Load case. I instantiate the object and programmatically add as it as a child, just like before. But ... I get nothing but a black window. No exceptions get thrown either. I'm baffled.
My question is, am I even headed down the right path? The page on XAML-and-event-handlers says you can use event handlers defined in uncompiled XAML in .Net Framework 4. Should I bite the bullet and just go to VS 2010 (I'm presently on VS 2008) so I can use .Net Framework 4 and just stick with uncompiled XAML? Are there any gotchas with doing things that way?
Or, if you do think the compiled C# DLL is a reasonable path, do you have any ideas on how I can debug the problems I'm having?
Or, is there a better and completely different approach?
Thanks in advance for your advice.
Polly
I think the right answer for this depends on some issues that only you can decide, but I'll start with the assumption that your C++ code base is big and complex enough that it is worth preserving.
Beyond that the next decision point is do you have UI (perhaps GDI) code in the C++ your preserving or only non-UI code. If you are attempting to preserve only non-UI code then I would consider pushing more UI responsibilty into C#. Perhaps you go so far as to build your views, event handlers, and maybe even view models in C#. This will enable you to take better advantage of the VS tooling.
If you've got extensive UI code in C++ to preserve then your current path makes a more sense. I don't think it will be impossible, but you'll have quite a challenge ahead of you. The key example here is Visual Studio 2010. It is the premiere example of a mixed application and has GDI and WPF side by side unlike any other app I've ever seen or heard of. There is a series of blog posts that I found pretty interesting that describe some aspects of what the Visual Studio team did to achieve this integration at The Visual Studio Blog.
I also came across this video Henry Sowizral on Refacing C++ with WPF in Expression Design that I have not seen myself, but discusses putting a WPF UI on top of an existing MFC C++ app.
Good luck.
I don't have any specific advice on the first part of your question other than to say that putting more responsibility in C# would allow you to build a small stub app if necessary which could go a long way toward diagnosing problems.
Thanks to everyone for the responses. On the matter of getting stuck on the C# DLL, I found this C++/CLI sample: http://msdn.microsoft.com/en-us/library/aa970266.aspx. Using that, I found my error, and was able to load the WPF without problems.
However, the whole motivation for loading the C# DLL was that I had understood that that was the way to attach event handlers programmatically. Following AresAvatar's suggestion, I found that I could use FindName to attach the handlers -- both within the C# DLL, but it also worked with my original loose-XAML approach. So, I didn't need the C# DLL after all!
It's all working nicely now. Again, thanks for all of your help and suggestions.
Has anyone else experience incredibly slow performance in the XAML editor in VS 2010? If I have a new project with a limited number of files, the performance is fine. However, if I have a project with a larger number of XAML files, the XAML editor hangs intermittently every few seconds, making it almost impossible to use.
I should also note that the performance is only slow in one particular project where I am referencing DevExpress 2010. I am not certain if this is related.
Any suggestions on solutions to this problem would be greatly appreciated.
Chris
In Visual Studio 2012:
Go to
Tools > Options > TextEditor > XAML > Misc
Check Always open documents in XAML view and uncheck Automatically populate toolbox items.
In Visual Studio 2015, 2017:
Go to
Tools > Options > XAML Designer
uncheck Automatically populate toolbox items.
This fixed my same problem.
If you don't need the visual designer, you can select a different editor in visual studio:
Right click the xaml file -> Open With... -> Source Code (Text) Editor
You will only lose the split view, intellisense etc. should still work.
If you need to check something in the designer you can still click 'view designer' to open the normal XAML editor again.
If you want to improve the performance of the visual designer, try checking DesignerProperties.GetIsInDesignMode in your code-behind. The visualiser instantiates your controls to know how to display them, thus executing parts of the code-behind.
Like the OP, I had extreme lag in the xaml editor on a project that relied heavily on DevExpress WPF controls. After trying unsuccessfully to resolve this issue with the other solutions posted here, I eventually tried deleting my Solution User Options (.suo) file, which is usually located in the same folder as the solution (.sln) file. This immediately resolved the issue. You may want to read this post about what visual studio stores in the suo file so you can reset anything important (such as build configuration - mine always defaults the active solution platform back to "Mixed Platforms" for example)
Short answer: if you do not use designer much, just replace the default editor for XAML, thus getting rid of XAML visual designer and speeding things up. Right click any XAML file, click Open with... and choose another default editor. Source code (text) editor works just fine.
Now it should be already fine. If you want to understand the details and completely get rid of the slow designer, read the long answer.
Long answer: Here is a nice explanation of what happens and why is it that slow.
A brief todo based on the aforementioned article in order to completely disable the visual designer of XAML:
Under Tools->Options->Text Editor->XAML->Miscellaneous->Default View check Always open documents in full XAML view
Open Task manager and end XAML Designer process XDesProc.exe (Note: for VS2013 right click this process and go to containing folder. Rename the exe to sth else, than end the process)
Standard XAML editor will load this process again (I guess it will not succeed with VS2013 and actions done in P.2). However, right click any XAML file, Open with... and choose another default editor. Source code (text) editor works just fine.
While using dev express, I've noticed some laggy response in the Visual Studio designer. This appears to be due to the license authentication of the DevExpress products.
If you delete the "Licenses.Licx" file (found in the project properties folder) you'll notice a marked improvement in performance.
Note: Removing the license file doesn't stop you from using DevExpress controls. But it does stop VS from constantly authenticating it.
I was wondering how programmers chose to edit XAML. Most of the programmers I speak to seem to edit the raw XML, but that seems nuts to me since it is such a natural thing for a more visual editor (of course you often have to get down to the raw code ultimately, but isn't there a better way to lay out a grid, or edit a template, or add non c# triggers or manage commands? The one that really set me off was editing a menu -- Visual Studio 1.0 had a better menu editor for C++ than the raw XAML editing experience.)
When I edit .aspx files I use a visual editor much of the time, and then for the raw stuff I get into the html code.
I am aware of Expression Blend, but that seems far more focused on artistic types and GUI experts rather than programmers.
Does anyone have recommendations for a better editor for XAML than VS? Especially so since VS seems to have real nasty problems with XAML editing too, like bugginess and poor performance?
Appreciate your helping this XAML newbie.
I must agree that Blend has the best XAML editor I've tried. While VS2010 has made some significant improvements over 2008, it's not at the same level as Blend, and still feels a little clunky and is prone to freaking-out.
A good option for doing quick and dirty XAML editing is Kaxaml, a small editor which can be thought of as NotePad for XAML. It's fast(er than VS), has syntax-highlighting, auto-completion and an in-editor preview. I find it quite useful to use alongside VS, although it is limited for serious work.
The Visual Studio 2008 visual editor for XAML is still fairly primitive as you've encountered. When it comes down to wanting a true visual editor for XAML files, Blend is your best bet.
Like you, I originally thought Blend was targeted more for designers, but after using it for awhile now, I've found that Blend is clearly the best tool to visually edit XAML files. And since Blend integrates with Visual Studio Team System, you are able to switch between Visual Studio and Blend fairly seamlessly.
I use Blend when I'm doing visual tweaking or setting up Storyboards. I'll sometimes use it when first laying out a window, as well, but I've found that it's often easier to just hand-code the XAML rather than relying on Blend to guess the layout I want. I use Visual Studio when I'm doing XAML editing by hand, as it has better Intellisense and automatic formatting than Blend. I never use the visual editor for WPF in VS.
Part of the challenge here is that XAML layout is much more sophisticated than WinForms, so simple drag and drop doesn't quite cut it anymore. Blend does a pretty good job of guessing what I want, but if I really want to clarify how the visuals should be laid out, it's easier to express by typing the XAML, now that I'm familiar with it.
My typical workflow:
Create the initial layout by entering XAML in Visual Studio for the Grids, StackPanels, DockPanels and what have you that will lay out the window or control. I may also drop in some of the other controls as well, if the layout is simple.
Open up Blend and use it to place smaller controls, edit control properties and create/associate any styles I need. If I need custom control or data templates, I'll create them from Blend and then repeat the VS/Blend process on those templates.
Go back to VS and edit the XAML to set up my designer data context and manually code the data bindings.
Use Blend to verify the look of the finished window or control with the designer data context, tweaking and styling as needed to polish the UI.
I go back and forth a lot, but I'm typically also approaching it from a different mindset with each tool. If I was working with a larger company, I suspect most of what I do in Blend would be handled by a graphical designer, which is I think the intention. I don't mind wearing both hats, though and I've become accustomed to using both tools, as needed.
Visual Studio 2008 isn't the tool to edit WPF window. It falls in error usually if you uses a complex xaml type or some advanced styles.
Visual Studio 2010 has added a lot of new features in editing and specially designer for binding and IntelliSense for xaml too.
Blend is true that is oriented for designers like Microsoft want to sell it but I find it more like the missing feature of the designer of VS.
Blend has an advanced editor for styles and animation and helps a lot to generate.
But Blend lacks terribly in editing raw XAML, it has no IntelliSense at all.
My choice is to use both VS 2010 and Blend specially for styles and animations.
Expression Builder is a good free tool
Would it be practical to create WPF applications without ever touching Visual Studio (or any other IDEs)? As in, coding and compiling completely within Vim and the command-line? What resources would you recommend for someone trying to do so?
It would be possible, since basically WPF is based on XAML - a variant of XML - and C# or VB.NET or another .NET language as its backend language.
The question really is whether that's practical and if it makes sense - I highly doubt it. WPF is all about visual design, e.g. totally without a visual designer (either the built-in one in Visual Studio, preferably the 2010 version; or some other visual designer), it seems a bit silly to want to program WPF....
As for resources - well, a least a text editor is a must, then definitely a few good books on WPF, and you could leverage the C# or VB.NET compiler that comes with the .NET framework.
I have found myself writing XAML in Notepad on a number of occasions where I needed to create a quick UI but couldn't load an IDE. It is really quite trivial, and almost - but not quite - as fast as using an IDE. The main advantages of an IDE such as Blend or VS.NET are in quickly getting things like colors and animations to be "just right."
Another occasion when I frequently write XAML or C# in a text editor is here on Stack Overflow. I only fire up Visual Studio when I need to test something out.
My main recommendations for creating WPF applications without an IDE are:
First you should make proper use of WPF's layout system, using appropriate panels and "Auto" sizing wherever possible. For example, if you want a stack of buttons with some space between them, create a <StackPanel>, and on each button add Margin="4" or whatever. This is good design anyway. Most beginning WPF programmers treat it like WinForms with no layout capability, which is a shame. WPF has a very powerful layout engine and it should be used. If it is, there will never be any need for graph paper or measurements. In addition, your UI will automatically adjust its layout if you change font sizes or objects are larger than expected.
Second you should use msbuild for your project unless it is ultra-simple. msbuild is installed along with NET Framework so it is always available. The file format is very easy to edit with a text editor, and it is much better than a batch file with the appropriate "csc" command because it allows you to use code-behind and is less error-prone when adding new source files.
Third keep a PowerShell command line window open separate from your editor, with a command that runs "msbuild" and then executes your application. To run your app, then just Alt-Tab to this window and hit uparrow, Enter. Some text editors have the ability to execute user-defined commands directly from within the editor and see the output, in which case this second window is not necessary.
Fourth keep a copy of cordbg or mdbg handy. Although an IDE is the ideal place to do your debugging, any debugger is better than none at all. You will find your problems much faster if you stop at breakpoints and examine variables than if you just keep editing code and re-running.
Fifth, use "ColorPad" or a similar application to select your colors for use. Just guessing and entering your best guess in hexadecimal just doesn't work very well.
For resources, I recommend you get the book "WPF Unleashed" and work through the examples. I would also read a lot of other people's XAML, such as can be found on CodePlex.
Possible, Yes. Practical No.
For production work, I would consider Microsoft Expression Blend 3. Then copy the XAML and paste it into the editor of your choice and compile from the command line.
You could download KAXAML . It's a free, lightweight editor. I found it good for learning about XAML and seeing how minor changes and tweaks can impact on an overall design.
XAML is plain old text so find a free editor (KAXAML), use it, and if you must, paste into your editor.
If you really want to go down this route, I'd recommend getting some graph (squared) paper and a sharp pencil.
Draw out your designs on that, read off the positions and type them into your editor of choice.
One benefit of this is that you're going to have a paper prototype to show people ;)
As James Keesey points out in his comment on marc_s's answer, your edit-compile-test cycle is going to be painful.
It's definitely possible. I'd say it's not practical, though.
To be honest, I do professional WPF development and I do it with the visual designer closed. I'm much more comfortable editing the XAML by hand, just like I write HTML. However, the benefits of an IDE go far beyond the visual designer. There's IntelliSense, debugging and a whole host of other invaluable features.
Really, I must question your motives. What are you trying to gain? Visual Studio Express editions fully support WPF development, so it can't, or shouldn't, be a cost issue.
The newest version (3.0) now supports the wpf template.
Just download it from: https://dotnet.microsoft.com/
Just type in console:
dotnet new wpf -o wpfHello
cd wpfHello
code .
Greetings :-)