Currently in my XAML editor view I am experiencing frequent seizing episodes of around 3 seconds each. I've been able to narrow down the reason for it to custom namespaces.
By default, my page has the 2 default XMLNS declarations:
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</Page>
This works fine, no seizing. However as soon as I add an XMLNS for controls inside my application it starts seizing up.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:controls="clr-namespace:MyNamespace.Controls">
</Page>
Its not specific to just that namespace. I've tried a large variety of namespace combinations. Basically any XMLNS pointing to one of MY namespaces causes this issue.
I'm not really sure how to diagnose this issue. Any pointers?
SOLUTION
We found out the solution. We had a reference to a Microsoft assembly that was about 7mb in size (ACtiveX stuff for web browsers). When removed, everything sped up. We're now looking at ways to abstract that assembly so that it can exist in the runtime folder but no need for a reference to it from the project. Thanks all for your ideas.
First of all we should find out what happens when you close quote mark inside Visual Studio. It's just a program (although a good one) - debug it/profile it.
Do you have any additional plug-ins
installed? Turn them off.
Turn off Intellisense.
What happens with MS Expression Blend? Does it seize?
Turn off all antiviruses.
Run Process Monitor and track what happens with VS. Are there any errors with file name/registry keys resolution?
If nothing helped, use profiler on Visual Studio process.
If nothing helped, write your question on StackOverflow. Oh. Hold on. You did this already. Let's wait for more responses :)!
Cheers!
This could be that it is looking for something or that it is recompiling code.
Select the output tag to view compile activity, then see if that is what it is doing next time it siezes up.
In some projects we get this behaviour if we exit debug mode by pressing the stop debug button instead of exiting the program.
Also, there have been several bugs reported for Visual Studio hanging when using DataGrid controls with WPF, it could be related to this. Here are a couple:
http://wpf.codeplex.com/WorkItem/View.aspx?WorkItemId=10542
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=420621
Are you running a real-time virus scanner? These can often cause sluggish performance when VS needs to compile your code...
A plausible guess is that this behavior is tied to VS's XAML editor attempt to provide Intellisense for nodes declared with clr-namespace. This is after all one of the differences between clr-namespaces and other types of namespace (whereby the URI is merely taken as a unique string, but no attempt is done to assert the definition of the underlying XML language.)
A possible workaround is too define the xmlns prefix under a bogus URI, during the xaml editing phase (and hence forgo any hints from intellisense), and to revert to the proper clr-namespace for other phases of the project.
Also, maybe adding the assembly=xxxx to the namespace declaration may help the situation. Even if the assembly in question is that of the current application, this may save the editor and associated intellisense some hesitation.
Another, counter intuitive workaround could be to have these controls in a separate assembly, as this may spare the system from the Intellisense's attempts at dynamically inferring the types structure from the source code, with all the associated hickups caused for example by the background polling for changes etc. (I do not know that it tries to do that, but sometimes, tools are getting to be quite intelligent, but too result in CPU or I/O blocks of the kind you describe.
Related
This might be a very newbie question (coming from a newbie) but I had some problems regarding the namespace. I've created a User Interface in Visual Studio and gave it a test name to start off and learn how to use the program and the programming language. I kept building and building my UI and now I'm at the point that I'm actually pretty satisfied with my work (and this community's help!). So I decided to change the name of the file from "Test" to something more relevant for my work.
Yet, unfortunately, I ran into some problems regarding the change of the Namespace. I know there are a lot of tabs where it needs to be changed, but I was wondering if there is an easy way to change the file name/namespace of the UI?
Thank you in andvance for replying and taking the time to explain this newbie what to do without breaking his UI ;)
Use tool like Resharper, it will do it for you automatically and safely.
With Keyboard shortcut:
Put the keyboard cursor to the namespace, press Ctrl + R + R and set the new name. It will change the namespace inside XAML as well.
With Mouse:
Right mouse click on the name space, click Refactor > Rename.
When renaming classes and variables there is the lightbulb-menu (Ctrl + .) in witch you can give Visual Studio the instruction to Change it for you. But this will not work with Xaml.
Visual Studio will not change Namespaces as far as I'm concerned. But you can still compile and look at the "Namespace not found"-Errors to change them manually.
As Yohanes Nurcahyo said there is ReSharper but only has a free Trial of 30 days.
I just found Xaml Styler and I'd like to give it a try. Can anyone share some experiences with this tool? Is it worth the try? Are there any drawbacks when using it in large teams?
Thanks!
I'm using it daily, and it's quite awesome. It's more than definitively worth a try, and I don't see any drawbacks.
Just make sure that everybody have the same settings, if you choose to divert from the default ones.
I absolutely love the XAML Styler. Though source control issues do happen. If you beautify a XAML document that can mean 1800 lines change if it was really ugly when you did it. If members of your team also have it checked out then they have to resolve 1800 lines of changes. So I recommend you be careful about when and which files you do this with in a team environment.
Trick: It beautifies the XAML page when that is the current tab and you hit [SAVE].
If you don't want the page beautified, then switch to a different tab and choose [SAVE ALL].
This is what I do when other team members have the same document checked out. If I'm the only one, then I do a normal save to make it nice, then check it in ASAP.
After using this tool for some time, I have to say that I don't recommend it because:
Attribute Definition Order Matters, and therefore the behavior might be altered when a XAML page is "beautified". The tool does not offer a setting to exclude attribute sorting. Here's more information on this problem: Silverlight XAML Attribute Definition Order Matters
Source control conflicts are actually a pain and there's no way to "force" the team members to use the tool. It would be nice for example, that the XAML files where styled when saving the file.
Hope it helps someone!
I started using this tool recently-- and I'm a big fan-- but one thing was really annoying me: it automatically formats everything whenever you hit save. I like using the green edit markup next to the line numbers in VS to keep track of where I am in big files. Whenever I hit save, it turns the whole file green.
So protip, if you turn off "Format XAML on save" in Tools>Options>XAML Styler, you can just right click on a file and hit format when you don't need your edit markup anymore.
Okay,...I've recently inherited a downright shocking Silverlight 4 application and the Xaml is worse than you could possibly imagine. I'm going through a clean up operation and I'm looking to save time if I can.
One of my problems is that I've got a bajillion Button controls; some have a Style set and some don't. I need a quick and easy way (if one exists) to remove all of the Style attributes from any Button (or whatever) that has one set. Is this possible?
I have access to VS2010, KaXaml, XamlPad and Blend 4.
Thanks in advance..
Forgot about this question so in response to Robert Claypool's question,...No, not really.
What I actually did was remove all the styles and go through the big daunting errors list one by one. I tried a little find and replace magic first but that failed miserably no matter how clever my Regex got.
No choice here but to just hand-ball it I'm afraid.
I'm using Visual Studio 2010 to create a small WPF application. I've created a user control that I am now trying to add to my main form. The user control does show up in toolbox but every time I try to drag the control to the form I get the error:
The enumerator is not valid because the collection changed.
I should know what's wrong and it is bugging me that I can't figure it out.
You have a bug in the constructor of the usercontrol - you are using a foreach-loop over an IEnumerable and while the loop is running, the IEnumerable is changed, this is not allowed with a foreach loop. Use a for loop instead if you are manipulating the Collection you are iterating over.
The problem here is that you don't know what code is throwing the exception.
WPF is terrible about exceptions, especially in constructors. The framework insists on catching and re-throwing a new exception, usually multiple times, and it's difficult to find the original stack trace. I've found the easiest way to track down this kind of error is to tell Visual Studio to stop as soon as the exception is thrown, rather than waiting until WPF has re-thrown it a couple of times and made the details difficult to dig out.
I don't have Visual Studio 2010 in front of me, but here's how to do this in VS2008 -- 2010 is probably similar:
Go to the Debug menu > Exceptions...
Next to "Common Runtime Language Exceptions", check the box in the "Thrown" column
Then debug your app again. It will stop at the line that's actually causing the problem, and it'll be much easier for you to see what's going on. And if you're still not sure why it's throwing an exception, you'll be able to post a code sample.
In order for a user control to function properly you need to have a constructor that takes zero arguments. This way the form designer has a way to render the control in a "default" manner.
I then overloaded my constructor to take the arguments I needed to actually run the control properly and everything worked as expected.
You need to:
Remove the DLL reference
Add a reference to your control
Rebuild the solution
Add your control. It should work!
I have created a class that is simply THIS
Class UserControlBase
Inherits UserControl
End Class
Then I changed the Inherits clause in each of my UserControls designer file to
Inherits UserControlBase
I know that generally you shouldn't manually mod the designer file. But in cases like this what else can you do? Is this OK? Is there a best practice I don't know about? Is there some other way to accomplish the same end (extending UserControl) ?
I have not had issue changing the Inherits line, adding Namespacing, or adding Imports/Using statements. If you need to do any of these 3, you won't find many other ways to handle these requirements.
I change them all the time in my C# projects... often it's the easiest way to duplicate something that you've done once in the designer to a similar form and you want to do the same thing in a different form. Visual Studio is perfectly capable of reading in your changes and incorporating it into the designer. I really don't know why there is a comment saying not to edit it. My advice would be just make sure you use source control, go ahead and edit it, test it well, and if it works, great, if not you can always back out your edits.
No. It's never a good idea to modify a file that's generated.
The Designer files are pretty simple code; the only thing that you'll typically find in there to complicate matters (but only slightly) is BeginInit/EndInit calls at the top and bottom of the file--between those the code is pretty forgiving.
*That said, do not put any code in there that will only execute at Runtime. Any runtime-dependant code will fail at design-time, so trying to open your control in Design view will blow chunks. It used to give you the Red Screen of Darn, but I'm not sure what effect the IDE has notwadays--but if things blow up and the usual tricks fail to remedy them then try removing your customized sections.
Further on that note (not to scare you, but rather to hopefully head off some of the difficulties we had) the means of determining if your code is executing in Runtime or Designtime often fail if your code is not part of the currently built solution/project.
So to bring it all home, simple UI layout/winforms modifications are perfectly fine to do by hand in the designer code. Databinding and external dependencies (with the exception of calling third party control libraries) should be cautiously approached.