Bugfixing R# 2.0 ?

Hi,

you are working on R# 3.0 and just released a bugfix release for R# 2.5. But what's about R# 2.0? Did you plan any more bugfixing
for it. The annoying bug with lost preferences when you work with Visual Studio 2005 and 2003 isn't fixed until now. I'm working on
a new project with Visual Studio 2005 and have to support an older .NET 1.1 project with Visual Studio 2003. It's nerve-shattering
to go to the options screen and change the settings each time change the Visual Studio version. For you to remember, the following
options are lost:

- Editor / Highlight current line
- Intellisense / Use intellisense of
- Highlighting / Color identifiers

I understand, that you won't spend time on the "older" versions. But there are many .NET-1.1 applications in the world which won't
be ported to .NET 2.0 so fast. So Visual Studio 2003 will be used for while (but hopefully Microsoft will support also .NET 1.1 in
Visual Studio "Orcas").

Regards
Klaus

16 comments
Comment actions Permalink


Our most complex (not in files but in "quirkyness") project took 4 hours
to upgrade to.NET 2

It's my experiene that .NET 1 projects can be upgraded with some motivation.
If your company doesn't already have VS2005 than there is still a problem
but it's a good thing you upgrade to VS2005 (fe debug visualiser)

It takes some effort but it allow the you and the R# team to focus more on
the future

Kind Regards, Tom

Hi,

you are working on R# 3.0 and just released a bugfix release for R#
2.5. But what's about R# 2.0? Did you plan any more bugfixing for it.
The annoying bug with lost preferences when you work with Visual
Studio 2005 and 2003 isn't fixed until now. I'm working on a new
project with Visual Studio 2005 and have to support an older .NET 1.1
project with Visual Studio 2003. It's nerve-shattering to go to the
options screen and change the settings each time change the Visual
Studio version. For you to remember, the following options are lost:

- Editor / Highlight current line
- Intellisense / Use intellisense of
- Highlighting / Color identifiers
I understand, that you won't spend time on the "older" versions. But
there are many .NET-1.1 applications in the world which won't be
ported to .NET 2.0 so fast. So Visual Studio 2003 will be used for
while (but hopefully Microsoft will support also .NET 1.1 in Visual
Studio "Orcas").

Regards
Klaus



0
Comment actions Permalink

Tom Pester wrote:


Our most complex (not in files but in "quirkyness") project took 4 hours
to upgrade to.NET 2

My company use a special Windows XP version which hasn't upgraded to Windows XP SP2 until now so we can't upgrade to .NET 2.0.

In my opinion it's not done just to compile a .NET 1.1 project under .NET 2.0. There are many compiler warnings which should be
investigated and you have to test the whole application in detail to ensure that it will work as in .NET 1.1. So you may be able to
port an application quickly, but if you have to guarantee that it works as before you have to do a little bit more.

Regards
Klaus

0
Comment actions Permalink

We haven't encountred breaking behavioral changes when upgrading to .NET
2 but there are indeed some warnings that indicate that some methods are
obsolete. These kind of things can be solved also quite easily and once you
know how you can do them in batch.

The special XP version is someting I never heard about. What is there special
about it? (Just curious)

Kind regards, Tom

Tom Pester wrote:

>> Our most complex (not in files but in "quirkyness") project took 4
>> hours to upgrade to.NET 2
>>

My company use a special Windows XP version which hasn't upgraded to
Windows XP SP2 until now so we can't upgrade to .NET 2.0.

In my opinion it's not done just to compile a .NET 1.1 project under
.NET 2.0. There are many compiler warnings which should be
investigated and you have to test the whole application in detail to
ensure that it will work as in .NET 1.1. So you may be able to port an
application quickly, but if you have to guarantee that it works as
before you have to do a little bit more.

Regards
Klaus



0
Comment actions Permalink

I do not know how you can make a statement like that. The last major update that I was involved in (70+ projects + 1 web site) from clean build to clean build took over six man months to complete. My experience in these level conversions is that this is fairly normal.

So for a lot of companies, converting is something that will be a long time coming yet.

David

0
Comment actions Permalink

Hi David,

Our most complex solutions was a about 12 projects and it took us 4 hours
with 2 man to upgrade.

The class projects were no problem at all : they upgraded without a problem.
The web application gave us the most trouble but it went straightforward
once we identified the issues. It basicly came down to the fact that VS2005
compiles more strict. Codebehind files that didn't exist in VS2003 were no
problem nut now it was. VS2005 insisted that the case of the class files
was correct and so on.

6 man months is just huge for upgrading 1.1 to 2.0 (I believe you though)
Why did it took so long?

Regards, Tom

I do not know how you can make a statement like that. The last major
update that I was involved in (70+ projects + 1 web site) from clean
build to clean build took over six man months to complete. My
experience in these level conversions is that this is fairly normal.

So for a lot of companies, converting is something that will be a long
time coming yet.

David



0
Comment actions Permalink

Well, I will admit that took a long time. The main problem with this
application was the history behind it.



The application started as a port from VB6 to NET 1.1. The initial
conversion to 2.0 had approx 400,000 lines of code to it. The initial,
naïve attempt to "just" convert it relieved over 10,000 hard errors
(admittedly they were valid!), even though they complied clean in 1.1.
The primary issue was poor coding; many classes had no strong typing at
all. So the next three man mouths were cleaning up all of the type
errors. Then came the web site. It was part of the structure of the
overall solution. That had to be broken out.



Once the problems with bad coding practices were cleaned up, the actual
conversion only took about 4 man weeks.



However, I have worked on a number of conversions that did not have the
bad coding issues, which took many man weeks to convert. Add a web site
in, and it just adds to the problem. The easiest one that I have seen
was about 1 man hour per project. Average without a web project seems
to be about 3 to 4 hours, and 5 to 10 if a web site exists.



David

"Tom Pester" <omegafantaDODELETETTHIS@telenet.be> wrote in message
news:86572545325ae8c95991184b8dc0@news.jetbrains.com:

Hi David,

>

Our most complex solutions was a about 12 projects and it took us 4 hours
with 2 man to upgrade.

>

The class projects were no problem at all : they upgraded without a problem.
The web application gave us the most trouble but it went straightforward
once we identified the issues. It basicly came down to the fact that VS2005
compiles more strict. Codebehind files that didn't exist in VS2003 were no
problem nut now it was. VS2005 insisted that the case of the class files
was correct and so on.

>

6 man months is just huge for upgrading 1.1 to 2.0 (I believe you though)
Why did it took so long?

>

Regards, Tom

>
>

I do not know how you can make a statement like that. The last major
update that I was involved in (70+ projects + 1 web site) from clean
build to clean build took over six man months to complete. My
experience in these level conversions is that this is fairly normal.

>

So for a lot of companies, converting is something that will be a long
time coming yet.

>

David

>


0
Comment actions Permalink

Gee - I will never moan about the code I work on again, my life is good after
all!!! ;)


0
Comment actions Permalink

Thx for the update David. I haven't encounterd such projects yet I must say.
And I hope the upgrade for such projects form v2 to v3 will be a lot smoother.

Eliminating bad practices and doing usefull refactorings will benefit the
project though. But iif it takes 6 manmonths than the guys from MS had to
do a better job designing V1 or the upgrade process in your particular case.


0
Comment actions Permalink

I have a bunch of code with some rather large regions defined for various
groupings of methods and properties and such.

When I'm at an #endregion, I can't collapse the open region from there... I
have to do it from the beginning #region line. It would sure be nice to be
able to easily navigate to the beginning of the region. The sould let me
easily skip through the file by region, as well as putting me right where I
need to do any collapse work. Simlarly a go-to end of region would let me
go right to where I want to add new code to a region.

Something to consider, maybe? Or is there some other way to do the same
thing?

0
Comment actions Permalink

I sure understand your problems, for several of our customers we have a
custom Windows XP embedded version we're maintaining which won't support
.NET runtime 2.0 anytime soon.

Converting from .NET 1.1 to 2.0 is not always trivial. As Klaus says, you
need to thoroughly test every part of the application. When we recompiled
one of our server applications for .NET 2.0 (it appeared to be a simple
recompile with just a few warnings), binary remoting between our 1.1 clients
and 2.0 server stopped working because of a DateTime incompatibility between
frameworks 1.1 and 2.0. There is a hotfix available for this bug (KB 907262)
but it has to be applied to every computer running 1.1 which is out of the
question for us (5000+ installations).

We also have an auto updating application which occationally won't restart
itself after we recompiled it for 2.0. It's probably a bug in our software
which prevents a worker thread to shut down properly, but regardless of
who's mistake it is the software behaves different in 2.0 compared with our
1.1 release.

I'm only doing bugfixes in 1.1 now so the R# problem isn't a big issue for
me, but I wanted illustrate that converting isn't always just a simple
recompile as some people seems to believe here.



"Luedi" <klaus.luedenscheidt@gmx.de> wrote in message
news:f11hgh$3c0$1@is.intellij.net...

Tom Pester wrote:

>>
>> Our most complex (not in files but in "quirkyness") project took 4 hours
>> to upgrade to.NET 2
>>

My company use a special Windows XP version which hasn't upgraded to
Windows XP SP2 until now so we can't upgrade to .NET 2.0.

>

In my opinion it's not done just to compile a .NET 1.1 project under .NET
2.0. There are many compiler warnings which should be investigated and you
have to test the whole application in detail to ensure that it will work
as in .NET 1.1. So you may be able to port an application quickly, but if
you have to guarantee that it works as before you have to do a little bit
more.




0
Comment actions Permalink

Hello Paul,

I have Ctrl-NumPlus mapped to Edit.ToggleOutliningExpansion and it collapses
region (and type and member) from any point inside it. Hope this helps you
too :)

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


PB> I have a bunch of code with some rather large regions defined for
PB> various groupings of methods and properties and such.
PB>
PB> When I'm at an #endregion, I can't collapse the open region from
PB> there... I have to do it from the beginning #region line. It would
PB> sure be nice to be able to easily navigate to the beginning of the
PB> region. The sould let me easily skip through the file by region, as
PB> well as putting me right where I need to do any collapse work.
PB> Simlarly a go-to end of region would let me go right to where I want
PB> to add new code to a region.
PB>
PB> Something to consider, maybe? Or is there some other way to do the
PB> same thing?
PB>


0
Comment actions Permalink

Woah, next time I'll download new articles before posting. Seems like
David got this covered pretty good already :)


0
Comment actions Permalink

Could the File Structure window be of some use here? If it is tracking the
carat in the editor or autoscrolling to source, you can navigate quickly to
the top of a region.

"Paul Bradshaw" <pbradshaw@advsol.com> wrote in message
news:f18gcb$9cb$1@is.intellij.net...
>I have a bunch of code with some rather large regions defined for various
>groupings of methods and properties and such.
>

When I'm at an #endregion, I can't collapse the open region from there...
I have to do it from the beginning #region line. It would sure be nice to
be able to easily navigate to the beginning of the region. The sould let
me easily skip through the file by region, as well as putting me right
where I need to do any collapse work. Simlarly a go-to end of region
would let me go right to where I want to add new code to a region.

>

Something to consider, maybe? Or is there some other way to do the same
thing?



0
Comment actions Permalink

Hello,

When I'm at an #endregion, I can't collapse the open region from
there...


Why is it so?

I have to do it from the beginning #region line. It would
sure be nice to be able to easily navigate to the beginning of the
region.


Ctrl+] would jump, in the default keymap.


Serge Baltic
Omea & R# Developer
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Hello,

The annoying bug with lost preferences when you work with Visual
Studio 2005 and 2003 isn't fixed until now.


It has been fixed in 3.0 (for the “3.0 vs 2.0” and “3.0 vs 2.5” scenarios).


Serge Baltic
Omea & R# Developer
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Serge Baltic wrote:


It has been fixed in 3.0 (for the “3.0 vs 2.0” and “3.0 vs 2.5” scenarios).



That's fine, but 3.0 isn't released yet and i don't want to use a Beta in a productive environment.

Regards
Klaus

0

Please sign in to leave a comment.