|
 WTE the coder has done? AtomicBoolean is already atomic and doesn't need a syncd block
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Source
|
|
|
|
|
Believe it or not, this reminds me of one UI programmed in Java that I saw about a year ago. It was demo of a software meant for lawyers. Somewhere in UI, there was was a search window and the user was expected to enter the Primary Key (a 10 digit number), the name of person and part of his phone number.
|
|
|
|
|
Maybe they could not figure out how to make a generic, synchronous handler that returned a User object?
This might as well be synchronous since it will block forever anyway. Are there any other threads involved here? Maybe some sort of Action pool? Maybe a similar model is used for full asynch?
If it is single threaded, it is equivalent to
User ret = userBase.invokeAction<User>(email,
new GetUserByIDAction(),
new GetUserByIDActionExecutionDetails(id));
if (ret == null)
throw new UserNotFoundException(id);
They had to use synchronized due to wait/notify.
|
|
|
|
|
I'm in the middle of writing an app that imports a ton of data from an old version of an application (written by commitee!) with about a dozen tables in it to a database of more than 80 tables. Of course, because of the horrendous nature of the existing data (and we NEED it!), it has to be edited, parsed, interpreted, scrubbed, validated, normalized, blah, blah, blah, and takes many passes to go through and build the new database. So, I'll wrap my automated scrubbers and importers in Tasks, to keep my UI alive and show me what's its doing along the way, right? Right!
Well, when you do that, the Tasks can "bloat" your stack trace when something goes horribly wrong. How bloated you ask? Well, the code can throw a stack trace of about 20-23 lines long. But, put that same code inside of a Task and blow it up the exact same way and the stack trace jumps to a mind blowing 163 lines, with inner exceptions going six levels deep! WTE!!
|
|
|
|
|
Have you considered writing robust code? 
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
There are always speed bumps on the road to robustness. 
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
