I am working in C# with Visual Studio 2017. I had previously made some changes to my form, and today when I run the code, the changes don't show up. It appears to be running an older version. Note that when I originally made the changes, it ran fine with the dropdown working.
Here is the edited version:
And here is what it looks like when it runs:
I have restarted VS and restarted my computer, both to no avail. I have searched extensively and can't find the answer.
Is there some setting I accidentally hit? Please tell me it's something obvious and not a weird glitch in the VS matrix.
Thanks!
You were using an old DLL/EXE.
This can happen in a few scenarios, typically if you store your binaries (DLLs built with your project) in source control.
You'd be surprised how many developers get caught out with this. It's often due to being pedantic about EVERYTHING being in source control - including the items you build!
Best thing to do is delete the bin and obj folders from source control. If it's a new project it's often easier to start fresh with a new source control project.
GAC'ing your DLLs is another common cause of this situation.
For the benefit of people working with WPF desktop apps with similar problems who get to this issue, here's a summary and workaround when your application window does not appear after the .NET 4.7.x framework upgrade.
Problem
After a basic upgrade of the .NET framework from 4.6.2. to 4.7.x the application main window was never shown and was hang in an infinite loop. The mainwindow.show() function never returned back to the application. The issue is Microsoft .net 4.7.x related but as it is not easy to debug and spot.
Root cause
.Net 4.7 included a new algorithm for allocating space to columns in a Grid declared with '*' in their widths. When an app is compiled for 4.7.x there's a possibility that grid sizing can cause the application to seize up in an infinite loop that can lock and freeze the application.
Originally posted by #SamBent in GitHub/Microsoft/dotnet#604
Solution / Workaround
Set the StarDefinitionsCanExceedAvailableSpace switch to true in the app.config to force using the old algorithm:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
</configuration>
Additional context
https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/runtime/4.7-4.7.1#resizing-a-grid-can-hang
The reported problem above is fixed with this workaround in my WPF desktop app. Hoping this might help others as the debug process can be quite hard. This issue is a .net 4.7.x bug and not solved by Microsoft.
I recently got a new computer and a copy of Visual Studios 2015. I opened some older projects (C#, winform, VS2010) and can edit the code just fine. However any changes to the UI in the designer, causes the entire UI to or not show part of the screen or glitch out.
Has any one ever experienced these issues? If so, how do I fix i?
Edit:
I discovered the issue has to do with the AutoScaleMode attribute of my project's form.
I wound up setting the form's autoscalemode to none. Doing that seemed to take care of my issues. I had to reorganize my UI but that was worth having the ability to use the designer again.
Yes I already searched and the solution on this post didnt work, my scenario is different.
I have a winform application, very simple, it was working, and now the error on the title of this post is shown when I try to open the form.
The only thing I have done is installed VS11 developer preview and vs 2010 SP1.
Any idea how to fix this?>
I managed to solve it, I checked on properties of the project and the framework selected was .net 4.0 client profile.
I changed it to .net 4.0 and then it worked.
by the way what does it mean client profile, what is it for??
Just had this happen to me. I was banging my head on my desk in frustration as to why. Closed and reopened Visual Studio and it was fixed. Weird.
My C# WinForms solution has two projects.
A DLL which is the main project I'm working on, and an executable WinForms I call "Sandbox" so that I can compile/run/debug the DLL easily in one go.
I'm working in .Net 4.0 for both projects.
Everything was working fine until I added some seemingly innocent code, and a reference to System.Web in the DLL.
Now my Sandbox project can't see the namespace of the DLL project. I didn't change anything which I believe should have affected this.
If I delete the project reference to the DLL from the Sandbox references and re-add it, then the red underlines all disappear and the colour coding comes back for all my classes etc; but as as soon as I try to build the solution, the whole thing falls apart again.
When I right-click the DLL project in the Sandbox's references and view in object browser, I can see the namespace and all the stuff in there.
I have a feeling this might be some sort of bug?
Is this some sort of VS2010 bug? I had this same issue a few months ago and I could only fix it at the time by making a whole new project and re-importing my files. This time, however, I have a bajillion files and will only do that as a last resort!
Edit:
After panickedly going through and undoing all my changes, trying to find what caused the problems, it seems to be this line:
string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);
If I comment out this line, then I get no namespace errors and the project builds fine. I can't see anything wrong with this line though.
I'm ready to declare this a bug in VS2010, this has bitten way too many programmers already. The fix is easy: Project + Properties, Application tab, change Target Framework to ".NET Framework 4" instead of the Client Profile that is selected by default.
System.Web is not included in the client profile. Having this option in the first place is quite silly, the client profile is only 15% smaller than the full version of .NET 4.0. Having it selected by default is even sillier. But I digress.
UPDATE: mercifully this all got fixed in VS2012. Which no longer makes the client profile the default for a new project. And the client profile got retired completely in .NET 4.5, good riddance.
Check to make sure that both projects are using the non-client profile for their target framework (go to each project's properties to do this).
One possibility is that the target .NET Framework version of the class library is higher than that of the project.
I faced this problem, and I solved it by closing visual studio, reopening visual studio, cleaning and rebuilding the solution. This worked for me. On some other posts, I have read the replies and most of users solved the problem by following this way.
Try building only the project with the Sandbox dll first independently.
Then point your executable project to the required dll and ensure copy local is set to true. in reference settings.
Tthen build the executable project.
Changing the target framework from the ".NET Framweork 4 Client Profile" to ".NET Framework 4" worked for me with a similar problem. I agree that the client profile doesn't seem to have much of an advantage to using it. I seem to get nailed with weird errors that I hunt for until I remember that Visual Studio defaults to the client profile. I guess the moral of the story when getting an error is: if "Rebuild Solution" doesn't work, check the Target framework...
If you tried already doing the Framework change, and still not worked, I hope this works for you (as it did for me): Simply add the necessary references from within your projects. Very obvious but I was doing it wrong until I found what was the issue.
I just had this issue and it turned out to be I had multiple namespaces being used that had the same object name (i.e. business objects had the same names as mvc models);
Fully qualifying the names fixed the issue for me.