I really really need 64bit Edit&​Continue

I work on a plugin for a popular G&G software tool.  The upcoming version of the tool will no longer support 32bit OS's.  That means my development environment will be exclusively 64bit and I will lose the ability to edit code during debug sessions.  The main app is ridiculously slow to startup and I will lose my mind having to restart each time I need to edit.

Does anyone know if MS is even working on this?  It appears that people have been complaining for > 3 years to no avail.  I guess most people just build for x86 and then switch for the final version, but my dll's will have to "mingle" with the 64bit executable and normally I can only make it compatible if I build in 64bit mode.

If anyone knows if this is in the works please let me know...I need something to look forward to!!!

64-bit Edit and Continue will be in a future release of Visual Studio.

It's also a f*cking nightmare to implement, and people get really edgy when their app breaks horrendously when the callframe gets messed up from Edit and Continue, so you'll just have to be patient - the priority at the moment is getting it to compile good ARM code, so you might have to wait a while.

Edit and Continue - Why do you even need this feature?  Having the ability to change code, in the middle of debugging, seems like a huge quality control nightmare.  Proper understanding of variable scope, proper usage of error handling should solve 99.99% of everything you hope to gain via edit and continue.

@lensman: I love E&C. I would never use it to change production code. Then again, I'd never be running in debug mode in production.

19 minutes ago,lensman wrote

Edit and Continue - Why do you even need this feature?  Having the ability to change code, in the middle of debugging, seems like a huge quality control nightmare.  Proper understanding of variable scope, proper usage of error handling should solve 99.99% of everything you hope to gain via edit and continue.

 

Oh you academics kill me. Come join us some day in the real world.

"Academics"?  I work for a living so please do not insult me! 

While I will admit my background does stem from a larger IT department, I still work with standards no matter how large or small the project.  Quality is built into a project from day one, not added after the fact.

I need it because everytime I start the main app I waste 3-5 minutes of my life.  I can fix bugs and even add code while using E&C so much faster.

44 minutes ago,Deanna wrote

I need it because everytime I start the main app I waste 3-5 minutes of my life.  I can fix bugs and even add code while using E&C so much faster.

perhaps the "G&G" whatever should fix thier startup time?

also as you have a plugin can you test it with a test program and not the "G&G" program ?

what about UNIT TESTING ?

honestly say 1 time a month i wish i could edit and continue, most of the time i focus on writting correct code that works when i run it.

7 hours ago,lensman wrote

"Academics"?  I work for a living so please do not insult me! 

While I will admit my background does stem from a larger IT department, I still work with standards no matter how large or small the project.  Quality is built into a project from day one, not added after the fact.

As in "academic approach". The GOAL can be for quality to be built into a project from day one but to state that itIS built in from day one is good salesmenship at best. Yeah I can pound my fist on my prideful chest all day long too.

6 hours ago,figuerres wrote

*snip*

most of the time i focus on writting correct code that works when i run it.

Yeah and after you work a long while writing tons of "correct" code, writing unit tests (which are built for free), and finally get around to actually running the damn thing (since it's so expensive to run it again and again, you've fogotton half of what you've written (kinda like this run-on sentence) so bugs are that much harder to figure out.

7 hours ago,DeathBy​VisualStudio wrote

*snip*

As in "academic approach". The GOAL can be for quality to be built into a project from day one but to state that itIS built in from day one is good salesmenship at best. Yeah I can pound my fist on my prideful chest all day long too.

*snip*

Yeah and after you work a long while writing tons of "correct" code, writing unit tests (which are built for free), and finally get around to actually running the damn thing (since it's so expensive to run it again and again, you've fogotton half of what you've written (kinda like this run-on sentence) so bugs are that much harder to figure out.

that's what you think?

that's not what i do.

for one thing you can and should write functions that are small'ish and you can test / run them and then build larger functions that call the others.

when a function / method is larger than about 30-50 lines it might be time to break it down into more than one....

yes that can lead to a lot of small functions if you do it too much, this is not a hard rule just a guide.

also i look for how to write less code, make things simple where possible.

@figuerres: E&C is a great time saver when fixing bugs in legacy systems that have large functions and no unit tests. Major refactoring is not in the budget.

2 hours ago,figuerres wrote

*snip*

that's what you think?

that's not what i do.

for one thing you can and should write functions that are small'ish and you can test / run them and then build larger functions that call the others.

when a function / method is larger than about 30-50 lines it might be time to break it down into more than one....

yes that can lead to a lot of small functions if you do it too much, this is not a hard rule just a guide.

also i look for how to write less code, make things simple where possible.

And you do that all for free right? You're just moving the costs around. I don't know what crystal ball you use to determine up front what those functions should be but for me and everyone I work with you start out big and break things down into small, refactoring as you figure out how you are going to impelment something (and test along the way).

Now I have worked with a guy who would pick up his patterns book for every problem he was trying to solve. We ended up gutting his code after terminating him. His code was just an endless layer after layer of wrappers that did nothing. Needless to say the net of his work was the wrappers and nicely patterned code that did nothing to solve the business issue hense why he was let go. Now I'm all for encapsulation but it's a rarity that you start with enough of the answer to a problem that you can start building everything so perfectly encapsulated.

1 day ago,spivonious wrote

@figuerres: E&C is a great time saver when fixing bugs in legacy systems that have large functions and no unit tests. Major refactoring is not in the budget.

This is exactly the point of E&C.  It's not meant for projects and solutions that are designed well (or can be changed), it's meant for sh*tty projects that should really be relegated to the scrapheap, but some marginally talented developer wrote it wrong and now YOU have to make his crap work.

Or something like that.

@DeathByVisualStudio:

The fact that some other developer took patterns and practices to an unneccessary extreme doesn't change the fact that cowboy coding just to 'solve the business problem' is worse.

And, while you don't know everything about how the app may end up being used, you DO know enough to know that separation of concerns (UI, Business, Data Access, Services) to know that this should be done.  Failure to do sowhen you have the opportunity is a sure sign of weakness.