I have a C# project in which the generated designer code throws an error at design time. Fixing the error requires me to modify the generated code, which gets overwritten every time I build.
The error is the generic full screen "To prevent possible data loss before loading the designer..." I can "ignore and continue" each time, but I can't seem to find a way to ignore it permanently.
Ignoring this permanently is highly dangerous and probably impossible. You'd be better served by determining the problem and fixing the bug in the offending control (assuming you are the author of that control -- if not, contact the author!).
Related
Whenever I change something in any XAML file in my Solution every reference in the Code Behind file will be marked as an error and IntelliSense stops working. but if I build the Solution everything works fine and IntelliSense works. Also just the files which are currently open show this behavior. As soon as I close it the errors disappears.
Should I be worried?
The errors you see when opening/editing a XAML are somewhat by design. It tries to do a quick test if your markup is valid, but in my experience, especially when using advanced bindings with custom objects, it will fail more often than it doesn't. This check is done to prevent you get errors on run-time, since most of the XAML is run-time evaluated.
So what you should do is check the messages, if you sure they are okay, just continue and see if the code actually works. If you see this error often, just ignore it.
I'm using VS2012 and .net 4.5. Whenever I edit C# expression in properties window I get message as shown in below image
Update:
I did not open this file. Neither in VS nor in other program. I think VS loads this file for some reason.
If I open C# expression dialog I get similar behavior to the one described here
I also often get error saying that VS cannot access this 'TemporaryGeneraterdFile_' cos it's being used by another process.
This post describes that error.
Did anyone experienced similar behavior?
It's realy anoing as it happens very often.
I have a very odd situation where by changes committed to the repository by my colleagues when updated to my local copy of the software, Visual studio doesn't recognise them immediately, and reload. the result (and this is very odd) is that most of the times, I will save my changes without the reloaded projects and will overwrite my colleagues changes. It is so embarrassing that sometimes I am asked why I had to change a piece of code and in reality I hadn't.
Another thing is, when I check in some VS project level changes like when someone added a new class, or form or anything and continue to work in Visual studio, it will take me at least 5 to 10 minutes before I get the warning that there was some changes and be asked to reload the project etc...
I think there should be a setting somewhere in visual studio to trigger an automatic reload, but can't find it.
This affect me and another person so far but mine is the strangest as it can take up to 30 minutes before a project start reload.
Any Ideas welcome
This is my settings
If you are working using Source Control, you will need to synchronise your local workspace with the server ("get" the latest code) before any changes by your colleagues will be copied to your PC.
If you don't "get" the latest code before you make changes then you may have to merge your changes with somebody else's, which can be a difficult, time consuming or even dangerous process - especially if you use the default Visual Studio automatic merge process, which usually does the wrong thing, resulting in essentially corrupt code (making it look like you deleted your colleague's works, just as you are describing, for example).
The best way to work with source control is the "little and often" approach:
Get the latest source code before you start any new work, so that your PC is as up to date as possible.
It's usually a good practice to "get" the latest code frequently (e.g. I do it first thing every morning) so that any merge conflicts are flagged up and dealt with as early as possible. The longer you wait before merging the worse the merge process tends to get. (Caveat: Check with your build system that the current version of the code on the server is working before you get it - you don't want to get broken code onto your PC as it may stop you being able to work at all).
Arrange your work as many small incremental steps that can be safely checked in as they are completed (rather than working for 3 months on hundreds of files and then dumping it on the system as one massive change )
When you are ready to check in, get the latest code, rebuild, and re-test your changes to be sure they still work when integrated with the latest program code. Only check in if everything works well.
Also be aware that when you try to edit a file, the source control provider may automatically "get" the latest version of that file for you (which could cause Visual Studio to tell you it has reloaded the file, and perhaps explain why you say it sometimes takes a while to "update", as it doesn't happen until you start editing a new file that has been changed recently by someone else). If this is the case, then the truth is that you have not "updated" the entire set of source code, only one file - in this case you really need to get all the latest changes to the source code (if you don't you may find it is uncompilable or (even worse), compiles but exhibits undefined behaviours due to only part of the code being up to date)
Lastly, a very good practice when checking in your code is to go through the list of files you are checking in and diff them one by one against the latest server code to see what you have changed. This may sound laborious but it confers several benefits:
It reminds you what you did, which can sometimes be helpful for filling in the check-in comment to clearly describe all your changes and make sure you don't miss an important note.
You will easily spot anything that has been screwed up in the merge process - there will be chunks of code that appear to be created or deleted that you know you didn't touch. So you'll be able to discover and fix these problems before you check in rather than annoying your colleagues by "deleting" their changes.
I find this very useful for finding temporary debugging code that I have forgotten to take out before I check in.
Sometimes you may even do a double-take on a bit of code you are about to check in and think "huh? why did I do that?". And then you might decide to re-examine and possibly even rewrite the code you thought was good to go.
Final Note: The options you show in your edit only relate to changes that are made to the files on your PC by another program on your PC. If another user makes a change and checks it in to source control, these options will have no effect. It is only when your Source Control system copies those changes to your PC's hard drive that you might see Visual Studio reacting to those changes (depending on how well your source control system is integrated with VS).
If you're sure the problem is Visual Studio (e.g. the file really has changed on the disk but you don't see it in Visual Studio)
Make sure that the Detect when file is changed option is checked.
Tools > Options > Environment > Documents > Detect when file is changed outside the environment
Since you are sometimes getting an alert to reload your project due to external changes means you already have the settings required to detect file changes in Visual Studio.
However, reloading of project/solution will only be triggered if the .csproj (or .vbproj) or .sln file was changed.
By the way, are you using some version control system? It seems that you are just sharing the solution and editing simultaneously.
I'm running a .NET 2.0 program on many computers. On one I had this error occurring repeatedly until I reset the application.
//line below was throwing the exception
this.myButton.BackgroundImage = global::myNamespace.Properties.Resources.myImage;
Exception:
ExceptionType: ArgumentException
Message: Parameter is not valid.
Source: System.Drawing
StackTrace: at System.Drawing.Image.get_Flags()
at System.Windows.Forms.ControlPaint.IsImageTransparent(Image backgroundImage)
at System.Windows.Forms.Control.set_BackgroundImageLayout(ImageLayout value)
The resource exists and it works fine once reset. Can anyone provide any insight as to might be happening?
I suggest you use Process Monitor to examine real-time activity on the file, and which processes might be locking it. Add a Filter where the Path is the name of the image/resource file; this should quickly show if anything is monkeying around with the file behind your back.
Yes, this is a 6 year old post! Ran into the same error today, and it took me far longer to fix than it should have. I was actually disposing my image control on startup, so I obviously couldn't adjust its background image on run-time. Might as well double check for that if you're here.
This is baffling me, I am unable to find this setting if it exists.
I am 90% sure that my code used to compile on save before.
I only started having this issue when using C#, .net worked fine.
But now I am only able to get rid of error lines etc, when choosing to enter debug mode.
For example when I have a method
public bool Method1(){
//No code added yet so I get a blue line saying return something
}
Even when I add what to return inside the method the line remains there on save. It only goes away when I build.
(This is just one example it seems to happen with lots of other things)
EDIT - In regards to options to compile on save.
The options in Build and Run are set Correctly
That should produce a red underline and an entry in the Error List window: "not all code paths return a value". It is produced by the IntelliSense parser, not the compiler. Saving the file does not remove the error hint, only opening another project does. And fixing the code of course.
There is a bug of sorts in this logic, in some cases the Error List doesn't get purged. The only workaround I've seen is to restart Visual Studio. I've only seen this with certain IntelliSense warnings and it only affects the Error List, not the editor. I can't remember the exact type of warning that triggers this, it only ever happened when opening a project with code I didn't write. These messages don't normally last long when I'm editing code. Which is by far the best solution.
Should it not be the other way around? Save on compile.
Anyway, you can simple change the ctrl+s key combination to build and save in the settings menu.