I am creating a XAML based application and running into a funky problem that isn't making any sense to me at all.
The problem: I make changes on my XAML, very minor ones such as changing the text content on my buttons. The design field reflects these changes as they should. However, when I run the project, the changes do not render themselves. The same window renders itself but the text content that was altered in the buttons do not change itself.
The problem is a microcosm of the bigger problem, which is that any kind of back end changes I make such as the data binding do not reflect themselves when the app is executed.
I am still exploring where i could be going wrong, but if anyone has any leads on this, I will much appreciate it!!!!
Thanks,
Parijat Kalia
Delete your pdb files from bin/debug and rebuild your application.
As I understand it, Visual Studio (the compiler, more accurately) sometimes does not detect small changes made to the code. Doing a Clean or a Rebuild (which, IIRC, is a Clean & Build) should force VS to recompile all files without needing to check for changes.
The logic behing the changes detection is to speed up compilation, compiling only the changed files.
Related
We have a complicated legacy form built in Winforms that recently has started seriously misbehaving and it gets worse and worse as time goes on. Just opening the form in design view will alter the layout of the form, sometimes in minor ways (a control is resized to be a pixel smaller) and sometimes in major ways (a component is moved to X position -6582). Due to the size of this form and the nature of the generated .Designer.cs referring to the diff is almost usually useless to determine whether the changes that were made to the form were the changes that you actually intended.
Based off a number of suggestions I found in other questions:
visual studio 2005 designer moves controls and resizes Form
Visual Studio keeps resizing my form without me telling it to, help!
Controls moving in vs2008 design mode on build
AutoScaleMode is set to None. I experimented briefly with various monitor resolutions, to no avail. Ultimately we decided to stop relying on anchors and instead use a combination of TableLayoutPanels and Dock properties. And that's when the trouble really started...
After heavily redesigning one of the hairier tabs on this form, when I tried to save Visual Studio spun for 2-3 minutes and reported "Could not load file or assmbly 'MyProject, Verion=X.X.X.X, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified" (as seen here: Visual Studio 2013 Can't save, build, or rebuild solution). This happened whenever the form attempted to save. After following the advice in the accepted answer, I was able to save/build again.
Attempting to run not much later resulted in a very, very long build time and a completely empty form (as seen here: All controls on a form are invisible and https://stackoverflow.com/a/5524183/1015495 ). All calls to Controls.Add had been removed from the designer (I assume this massive change is what resulted in the long build time). I restored the form to a previous version and began recreating my changes. Now, much more insidiously, certain controls have had all of their children removed.
Working within this form is becoming a timesink at best and unfeasible at worst. The solutions that I've found online basically boil down to "recreate the form manually" or "don't use Winforms". Unfortunately neither of these are an option right now. How can we mitigate the problems that we're having with this form in the mid-term future until we can come up with a proper fix?
I am working through an almost identical problem at the moment and mine seems to be a bug in Visual Studio 2013 related to having a "linkLabel" control on a User Control, which is on one of the tabs of a tab control on the main form.
I had other linkLabel controls on the parent form that did not cause any issues. The weird thing is that not ALL of the tabs were messed up, only some of them. I can only conclude that it gets through part of the layout restructuring, hits the user control, and bombs out, failing to finish the layout correctly. I attached a second version of visual studio to try to catch exceptions, and saw various status lines showing up in the debugger, but did not see any exceptions thrown. I am not that familiar with doing that, so it's possible I did that wrong though.
I could revert the code back to after I had added the user controls, but before VisualStudio opened the form in the designer and automatically re-generated the designer code. At this point, opening the form in the designer will always cause exactly the same design failures. As long as I never opened the code in the designer again, everything would work correctly at run time.
If I removed any reference to the custom user controls with link labels, the designer would also open without any trouble. At first I assumed I had an error in my own code so I started commenting things out, but it was still happening even with just the basic elements dragged on. So then I started removing elements and adding them back one at a time to see what broke it. In my case this turned out to be the "linkLabel" control. I am not sure if there are other controls that will do this yet. For now I just plan on re-writing the code to not use a link label on the user control though and see how well that goes.
When opening a Form in the Visual Studio Designer, the generated designer files' contents get mixed up randomly. This includes the files
Form.Designer.cs and
Form.resx
When using a version control system this is a real nightmare.
Is there a way (extension?) that sorts and cleans up all designer files before saving? This would solve most of my VCS related issues with WinForms, as it reverses all the shuffling the designer does.
This problem sure does make merging difficult - I understand your pain.
Read this previous SO post:
"Why does C# designer-generated code (like Form1.designer.cs) play havoc with Subversion?"
Basically you could create a tool to sort all the code alphabetically to give order to the random placement of code, but it is a hack and could involve a lot of pain itself. Personally I recommend changing your work practices to reduce this occurring.
Reduce time between merges
Limit access to a form to 1 developer at a time.
Merge under the guidance of the developer who made the change, as they will know better what looks ok.
Don't open the designer, if you are only making a "code change", ie nothing changes visually.
Undo changes to the designer file before merges, if you are 100% sure that you didn't change anything.
This is not a tip about automatically sorting Form.Designer.cs; however, it does help with avoiding merge help with all modifications made to Form.Designer.cs-files by Visual Studio.
Instead of (or in addition to) changing your work practices (by Jonathon Lee) and especially the constricting "Limit access to a form to 1 developer at a time" do:
Ensure the Form.Designer.cs-file is organized according to Visual Studio in a separate commit before you make the real changes.
Trigger a reorganization of the Form.Designer.cs-file by Visual Studio
(For me, moving a control from one cell in a TableLayoutPanel to an other and back again did the trick.)
Commit Visual Studio's changes and mark them as nothing changed.
Make your modifications to the Form
Trigger a reorganization of the Form.Designer.cs-file by Visual Studio
Commit your changes and describing your work.
Results:
This helps reviewers to distinguish changes to review from noise.
This eases merging:
either, your version control system detects that two commits have the same effect and one is enough and it can merge without conflicts;
or, you manually resolve the conflict by applying just one of the cleanup commits and discard the other.
I have a UserControl which is a Tab. It inherits from a base UserControl. My project is under SVN.
Each time I open the UserControl in the designer I have slight code change that seems to automatically happen. Such as System.Point changes to the Location property of controls. What I am facing is these small changes ultimately cause a pending change in SVN and if I am not extremely cautious in my check-in process I can inadvertently check-in changes that weren't done by me, but visual studio.
Has anyone faced this? Does anyone have any suggestions as to a resolution?
I have a winforms application that I am writing in C# - in Visual Studio 2010. I have one specific form that keeps corrupting itself every other day or so - according to TFS, it looks like most of the file is re-written by the designer when I have made only the smallest changes. (location of buttions, etc.) Things fall off strips, toolbars, etc. as well as errors just trying to use the designer. See my other post Here. (Thought I figured this out, but I guess not)
Here is an example piece of code that goes missing - when I put it back in, it takes it back out when I save the file. The code was generated by the designer in a previous file version.
this.statusStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {
this.tssEmployeeName,
this.tssLoadTime,
this.tssSpring,
this.tssHomeLocation,
this.tssTotal,
this.tssDue});
Is there any way of 're-generating' the [file].Designer.cs file? Or should I bite the bullet and re-do this form? (pain with over 100 components on this one...) It's the only form I have a problem with out of the 35 or so in the project.
VS 2010 w\ SP1.
Thanks, Andrew
I've experienced this before, although I'm not sure if my issues were exactly the same.
Try putting a handful of problem controls, such as your StatusStrip control and its children, into separate User Controls. Then add those User Controls to the main form instead. At the very least, you can prevent the designer from rewriting those controls.
I have a solution with many projects. One project contain few custom components. One of these components is used to display a title on an image. We can change the color of the background and many other things.
The problem is IF I decide to change the default color of the background of the component or change the position of the text, thoses change won't reflect in all other projects of the solution where the component is used. I have compilent the project of the component and all other projects Reference the component by the Project.
For the moment, what I have to do is to take off the component from the other project one by one and to add it back, then all is fine. Do you have a quick way to do it?
UPDATE
I have added a CheckBox inside that component and it seems that the checkbox is everywhere! Fine! But when a property has a some tag that let the component to change (example like the Background color) it doesn't change the "default" value but instead put the old value as a changed value in the property. So, I see the old value setted like if I add manually changed the color in the Properties panel when I haven't...
UPDATE 2
alt text http://img517.imageshack.us/img517/9112/oldonenewoneei0.png
Update 3:
This problem is still here. Just to let people know that I am still curious to find a way.
I have tried few of your suggestions.
If I clean all the solution and build only the project that has the Custom control then I build the solution. Nothing change (To test it, I have change the color of the component to Yellow. Nothing change : fail.
If I remove the reference and add it back to the project and then rebuild the solution. I can see the old color in the designer : fail.
I have updated the question with more information and an image (above) for those who want to try to help me.
As you can see, the old "compile" of the component show the Yellow background but when I insert a new component (from the Left Tool bar in Visual Studio) I can have the new component with the supposed WHITE background...
This is most likely due to references.
Your other projects probably copy in a reference to your component project. You'll have to rebuild these other projects for them to re-copy in the referenced component project, if it has changed. It is only updated at build time.
You can somewhat get around this by having them part of the same solution. In that case, you can set up your project dependencies correctly and it should handle things for you mostly automatically. But having everything in the same solution isn't always the right thing to do.
If you already have them part of the same solution or it's not a references problem, it might be due to component serialization. We've run into this quirk a lot when doing custom control development.
My guess is that the designer is smart and remembers the settings for the component as you have it in the designer and thus sees it as the default.
This doesn't sound usual. Right clicking on the solution and hitting "Clean Solution" might help (it will delete all dlls and executables from each project's bin directory, which forces fresh builds to occur)
You might also want to check your build order sequence.
I work on a project that has a similar problem, I have found that if you touch the .NET config file or assembly information file (depending on your project type). The other projects will then reflect the component change...
I'm not sure why this happens, but this is how I overcome it...
Recently I have switch to building everything via Nant, and that takes care of the problem altogether.
Sometimes the Visual Designer serialize all your properties in the code-behind, even if they have the default value.
If your component have a default backcolor of Red, and you change the default backcolor to Blue, the components that use your component will change it back to Red.