|
You're simply not trying hard enough. Put each iteration of the loop in a giant try-catch and quick as a Hollywood marriage all your problems are sorted. You could even go the extra mile and log the exceptions.
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
Yeah, right! Too bad I need to fix all the problems with the data, otherwise I would ignore 'em and log 'em. The script the app runs already generates about 120MB worth of log data just showing what it sees in the data and what it does to it.
|
|
|
|
|
Has anyone else come across the bug in Visual Studios 2012 where it runs code that isn't there?
I created an application and then I decided against some of the features I had in the application. So, I removed them. Buttons and grids etc. were removed, but alas, Visual Studio 2012 is so epic, it still ran all the missing code and displayed everything I removed.
I went further into this and decided to start from scratch, deleted the entire application and started a new one with the same name. It obviously didn't delete the previous project code completely, and had it stored somewhere, after it had deleted the actual project, so when I finished creating the new application, it ran like the old one. FML. So I removed EVERYTHING, all code, and the entire GUI and it still ran. WTF? I eventually copied the code, pasted it in notepad, and started in a blank app instead of Windows forms. Pasted the code back and added everything else manually.
|
|
|
|
|
Save the changes in the files, Rebuild the project and run it
|
|
|
|
|
Could it be that you had build errors and selected the option to automatically run the last successful build?
|
|
|
|
|
|
But why would it still be there after recreating the project as empty?
|
|
|
|
|
An empty project is obviously an error....
|
|
|
|
|
For some reason or another, it obviously didn't build it again before running. I'm guessing you either disabled the auto-build or (as mentioned above) you had a build error and had it set to always launch the last working build in that situation.
Sounds like PEBKAC to me
|
|
|
|
|
On occasion, a build doesn't go quite right for some reason and the final .EXE isn't updated. I haven't seen that problem since the VS2005 days.
The solution to the problem is easy: Build menu -> Clean Solution then Build your solution again and run it.
|
|
|
|
|
Had to do the old "clean solution" a lot back in the old days...
|
|
|
|
|
I've only seen that when C# is involved. It makes copies of all the using DLLs. So if DLLs use DLLs, and there are 100 projects in the solution, you could end up with 100 copies of the same DLL. The problem then is if you change one of the DLLs. It sometimes doesn't get re-copied and the whole build falls over in a heap. I've got scripts just going round deleting all copies the DLL I am rebuilding.
|
|
|
|
|
All I've ever done is make the external .DLL's part of the project and mark them "Copy Always". If there was a problem, Clean always worked. I never had to build a special script to do any of this for me.
|
|
|
|
|
One of my colleague had same kind of issue sometime before.
So just try this:
1. Close all the VS and Sql server instances compulsorily, and also browsers and other apps/tools if possible.
2. Stop the local IIS if you are using it.
3. Now, delete the temporary files from the system wherever applicable. Usually you find in Quote: C:\Users\YourUserName\AppData\Local\Temp and Quote: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files and also delete browser temp files if possible.
4. Restart the system.
5. Once system is up, open your project solution in VS and do 'Clean solution'.
6. Build the total solution and then verify whether its fine now.
Hope this help you.
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter.
Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder.
Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
My blog - My recent article
|
|
|
|
|
Mohammed Hameed wrote: 2. Stop the local IIS if you are using it. Most likely it is IIS Express at fault, that you must close in the system tray. I've very often found that to me the culprit of ghost code.
|
|
|
|
|
Ugh. IIS Express. Where one has no idea about which Sites exist and where they are located. Lot's of fun removing old builds/projects...
Yeah, I know there is a config file where every site is listed as in the normal IIS.
|
|
|
|
|
Next step, Format the machine with no Backup and start all over.
Now serious.
When i have situations like that i usually hunt down and kill all of possible Bin files the project is using. Then Rebuild and my problem gets solved.
Paulo Gomes
Over and Out
|
|
|
|
|
I've had the issue where removing buttons and textboxes did not actually remove them after compiling, I eventually tracked it down to a missing
InitializeComponent(); in the form constructor.
Haven't seen the issue where everything is there after creating a new project though.
I found VS 2012 to be quite buggy so I've stuck with VS 2010 for now.
|
|
|
|
|
Mine does that ALL THE TIME.
No chnages I make show up unless I Rebuild rather than build.
And yes, that's even with it set to rebuil automatically.
Only annoying when I forget it does it, other than being annoying on general principles.
|
|
|
|
|
I have had similar issues after updating a WCF reference. I do a "clean" and then manually delete the obj subfolder. Then I rebuild. Works every time I try it.
|
|
|
|
|
MS' standard approach to everything these days seems to be to make something that sometimes works and can possibly be made to work eventually, with luck. Nobody seems to give a damn if anything is *correct*. Your particular story sounds like a corrupted build cache. Ever noticed the "clean" menu item? That is specifically for working around when VS has messed up it's caches and make sure everything gets made from scratch.
Granted, having a build cache does help a lot with build speed in many cases, as VS sometimes manages to correctly work out what has changed and must be rebuilt, and what hasn't and can be taken from the cache. I'll also grant that it may not be completely trivial to ensure the cache status is always correct, given that you may change files in all sorts of ways besides within VS, and given that build actions nowadays may encompass all sorts of things besides just compiling some code (e.g. code generators often execute immediately prior to build).
Even so, it does amaze me how VS sometimes manages to mess it up all by itself. The simplest solution consisting of a single console application project with a single Program.cs file and doing absolutely nothing outside of VS may still cause it to stubmle. But this sort of thing is perfectly in tune with how VS behaves in other respects. It can't modify a file because "another process" is using it, and it turns out it's VS blocking VS. It confidently asserts "all files are up to date" when solution explorer shows a folder with hundreds of files, and your working folder is empty. And for most of these, what do they do? Fix it, so VS behaves correctly? Oh no. They add a special menu option and name stuff so it seems as if YOU are at fault rather than VS. I chuckle whenever I need "get special version" in order to get the latest version and the dialog offers me the choice to fetch files even when the local version matches the specified version. Now what could *possibly* be the point of spending time to replace a file with an identical file? Clearly, MS knew full well about the problem, but was too embarrassed to honestly state "get file even if VS believes it already has it, as it sometimes mistakenly thinks so"....
I'm sure others could add many other examples of this general pattern of sketchy workarounds on top of semi-working base functionality. At least the glory days of VSS have passed - some people lost their entire source history due to it's tendency to occasionally corrupt it's own database files...
|
|
|
|
|
Not in VS 2012, but over the years, yes.
Browsers have cached my files and reused their cached files rather than my new ones.
Clocks have gone wacky on me, resulting in derived files (e.g. executables) with future dates.
Network file systems on machines with wildly different clocks have resulted in future date issues.
Revision control system have restored a file's date.. from a server with a skewed clock.
Precompiled headers have cached old code, which then got used in the build instead of the modified code in the source file.
I've even been the problem on occasion, doing stupid things that caused files not to be rebuilt after changes.
Clearing cached files, and cleaning all derived files and rebuilding, has fixed it for me. However, VS is historically deficient in deleting all derived files, so you may have to find and remove them by hand to truly get everything to rebuild.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
It sounds to me as though what happened is this: after you'd made your changes, there was a bug in the result - a syntax error or something - and when you came to run it, VS ran the previously-compiled version without telling you... so it looked as though your changes weren't taking effect when in fact, the new code was never compiled. There's something in the options to make it not do that - can't remember where - but by default, that's what it does. It's caught me by surprise a couple of times, too...
|
|
|
|
|
We call them ghosts in the machine...
|
|
|
|
|
Lmao, Ghosts is about right. This had me going for weeks. I just thought it would be something interesting to post and see what encounters other people have had. I seem to find all sorts of bugs with computers and Visual Studios though. The other day my computer told me it couldn't find an operating system, then I restarted it and it worked fine. I thought maybe a good line of work would be penetration testing, considering I'm good at finding bugs, and loopholes.
|
|
|
|