Build 75 Install problems

Been using various builds of Resharper and so far been really impressed.
Tried installing 75 over 73 today, the install failed - one of the
components appeared to fail registration and rolled back. So I removed
73 and re-installed. This time appeared to work. When I started VS.NET
with any of my solutions Resharper through an exception. I've sent the
stack trace using the automated tool.

However I then started VS.NET and it claimed that Resharper had problems
would I like to remove the add-in. I said yes and then de-installed. Now
the deinstall and install fails, claiming some issue with the
Extensibility assembly. This also seems to have screwed all of my addins
(NUnitAddIn and QuickCode). NUnitAddin now complains that it can't find
the assembly 'Office'.

Has Resharper removed a shared assembly?

I've attempted to remove all add-ins and re-install to no affect.

I'm currently in the process of repairing the VS.NET 2003 installation
in the hope that this resolves the problem.


Darren

15 comments
Comment actions Permalink

I got the same problem. The #75 uninstallation causes VS.NET not to work properly. I could not create a new project properly. When I tried to do that VS.NET will complain that some DLLs are missing. I have to reinstall #75 to make it work again.

0
Comment actions Permalink

Agreed - same resolution. Had to remove and then re-install VS.NET, for
some reason the repair failed.


Darren

0
Comment actions Permalink

It seems that ReSharper installation accidentally removed some required path from PATH variable. After adding it back manually, it's back to work again :)

0
Comment actions Permalink

Hi,

we've fixed some problems with removing shared files in the next build. As
for the PATH
variable, I have no ideas why this may happen. Could you tell what paths
were missed?

Thanks,
Dmitry

"Nat" <no_mail@jetbrains.com> wrote in message
news:28766561.1080880137794.JavaMail.itn@is.intellij.net...

It seems that ReSharper installation accidentally removed some required

path from PATH variable. After adding it back manually, it's back to work
again :)


0
Comment actions Permalink

I don't know why but VS.NET cannot locate C:\Program Files\Common Files\Microsoft Shared\MSEnv\VSProjLang.TLB. Any idea?

0
Comment actions Permalink

You perhaps need to register it manually if it was unregistered during
uninstallation.
We've excluded this file from installation package.

"Nat" <no_mail@jetbrains.com> wrote in message
news:3809772.1080911268404.JavaMail.itn@is.intellij.net...

I don't know why but VS.NET cannot locate C:\Program Files\Common

Files\Microsoft Shared\MSEnv\VSProjLang.TLB. Any idea?


0
Comment actions Permalink

I don't have to re-register the file. The file is used by VSProjLang.dll (interop dll). Just adding it to PATH variable did the trick. I checked in another machine that doesn't have ReSharper installed. It doesn't have the PATH to VSProjLang.tlb either but it works. Hope this helps you investigate why it happened.

0
Comment actions Permalink

Hi,

I think your fix in 1556 should do the trick. I figured out that #75 installer removed HKCR/TypeLib/{49A1950E-3E35-4595-8CB9-920C64C44D67} which pointing to VSLangProj.tlb

0
Comment actions Permalink

I can't login to see 1556... what's the suggested recovery? Path, register
the type lib, re-install VS.NET (eek)? Anything special about registering
VSLangProj.tbl?

/jhd


"Nat" <no_mail@jetbrains.com> wrote in message
news:26576385.1081167665809.JavaMail.itn@is.intellij.net...

Hi,

>

I think your fix in 1556 should do the trick. I figured out that #75

installer removed HKCR/TypeLib/{49A1950E-3E35-4595-8CB9-920C64C44D67} which
pointing to VSLangProj.tlb


0
Comment actions Permalink

Ok, found a number of VSLangProj[2].* files... the following being the
likely candidates. Any significance to which I register? Arbitrarily
registered ...\Common

VS.NET hanging on solution load. Any help appreciated. Guess i'll try adding
the directory(s) to the path next.

/jhd

C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\IDE\PublicAssemblies
C:\Program Files\Common Files\Microsoft Shared\VSA\7.1\Common

Directory of C:\Program Files\Common Files\Microsoft Shared\VSA\7.1\Common
03/19/2003 04:52 AM 53,248 VSLangproj.dll
03/19/2003 04:52 AM 19,968 VSLangProj2.dll

$ regasm VSLangproj.dll
Microsoft (R) .NET Framework Assembly Registration Utility 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

Types registered successfully


/jhd

"Nat" <no_mail@jetbrains.com> wrote in message
news:26576385.1081167665809.JavaMail.itn@is.intellij.net...

Hi,

>

I think your fix in 1556 should do the trick. I figured out that #75

installer removed HKCR/TypeLib/{49A1950E-3E35-4595-8CB9-920C64C44D67} which
pointing to VSLangProj.tlb


0
Comment actions Permalink

Rebooted (maybe forgot to)... current status as follows...

2 Exceptions on Solution load (400 error trying to web submit)
GetFullPathHelper()... new, for me, .75 build
exception trying to reference unloaded app domain... same as .73

"Loading Assemblies" still pretty slow

ReBuild solution... I'm getting a "Loading Assemblies" for each project in
the solution. Never noticed this before. Is this new to .75?

.73 comment... VS.NET freezes fairly often. This is true for both medium
forms based files (bunch of InitializeComponent() stuff), say avg 1500
lines. This is true for small to medium size class files as well, say
200-500 lines.

I'm running a default ReSharper config. After reviewing the forum I see a
number of comment about turning off syntax highlighting in regard to vs.net
lockup (where vs.net is consuming 96%+ cpu). Guess I'll turn it off and see
if it helps.

Oh yeah, can someone please comment on my older thread titled "Font Size
Trauma"?

/jhd

"Nat" <no_mail@jetbrains.com> wrote in message
news:26576385.1081167665809.JavaMail.itn@is.intellij.net...

Hi,

>

I think your fix in 1556 should do the trick. I figured out that #75

installer removed HKCR/TypeLib/{49A1950E-3E35-4595-8CB9-920C64C44D67} which
pointing to VSLangProj.tlb



0
Comment actions Permalink

John,

1) Exception with GetFullPathHelper should be fixed in the next build.

2) That you get 'Loading Assemblies' on rebuild is probably caused by that
you have
references to managed C++ projects in your projects. ReSharper loads the
compiled output
of managed C++ projects just like the VS does (but unfortunately our
assembly loader currently works
much slower) - this feature has been added in the build 75. But it reloads
compiled assembly only after
you rebuild the C++ project. Does this cause significant slowdown for you?

The benefit is that ReSharper now recognizes the classes declared in C++
projects, so you can use them
in code completion, references to them are not highlighted in red etc.

3) Lockups and freezes: there are currently some problems causing them when
highlighting. However,
we only observe this on large files. If you experience them on small files
(you say 200-500 lines) may be
these files contain very large methods or smth similar irregularities? If
you could provide such a file so that we'll be able
to test it, it would be really great.

Thanks,
Dmitry

"John Dhom" <a@b.c> wrote in message news:c4umdb$tih$1@is.intellij.net...

Rebooted (maybe forgot to)... current status as follows...

>

2 Exceptions on Solution load (400 error trying to web submit)
GetFullPathHelper()... new, for me, .75 build
exception trying to reference unloaded app domain... same as .73

>

"Loading Assemblies" still pretty slow

>

ReBuild solution... I'm getting a "Loading Assemblies" for each project in
the solution. Never noticed this before. Is this new to .75?

>

.73 comment... VS.NET freezes fairly often. This is true for both medium
forms based files (bunch of InitializeComponent() stuff), say avg 1500
lines. This is true for small to medium size class files as well, say
200-500 lines.

>

I'm running a default ReSharper config. After reviewing the forum I see a
number of comment about turning off syntax highlighting in regard to

vs.net

lockup (where vs.net is consuming 96%+ cpu). Guess I'll turn it off and

see

if it helps.

>

Oh yeah, can someone please comment on my older thread titled "Font Size
Trauma"?

>

/jhd

>

"Nat" <no_mail@jetbrains.com> wrote in message
news:26576385.1081167665809.JavaMail.itn@is.intellij.net...

Hi,

>

I think your fix in 1556 should do the trick. I figured out that #75

installer removed HKCR/TypeLib/{49A1950E-3E35-4595-8CB9-920C64C44D67}

which

pointing to VSLangProj.tlb

>
>


0
Comment actions Permalink

2) rebuild/loading assemblies

Understood, thx info... The delay is tolerable, more so if I could depend on
vs.net to accurately sort out my project dependencies ;) I guess my ui
widgets (infragistics) are managed c++.

3) lockups/freezes
Yes, small solution, half dozen assemblies, mostly small files. I'll see if
I can ship you the solution. Is there some kind of NDA (non-disclosure) in
place (I'll be asked ;))?

Update...
VS.NET now locking up during solution load... after processing Loading
Assemblies for a while it goes Not Responding like Attached (for > 10
minutes). Will try another reboot cycle... may need to wait for next build
:(


/jhd

"Dmitry Shaporenkov (JetBrains)" <dsha@jetbrains.com> wrote in message
news:c4un8e$3ao$1@is.intellij.net...

John,

>

1) Exception with GetFullPathHelper should be fixed in the next build.

>

2) That you get 'Loading Assemblies' on rebuild is probably caused by that
you have
references to managed C++ projects in your projects. ReSharper loads the
compiled output
of managed C++ projects just like the VS does (but unfortunately our
assembly loader currently works
much slower) - this feature has been added in the build 75. But it reloads
compiled assembly only after
you rebuild the C++ project. Does this cause significant slowdown for you?

>

The benefit is that ReSharper now recognizes the classes declared in C++
projects, so you can use them
in code completion, references to them are not highlighted in red etc.

>

3) Lockups and freezes: there are currently some problems causing them

when

highlighting. However,
we only observe this on large files. If you experience them on small files
(you say 200-500 lines) may be
these files contain very large methods or smth similar irregularities? If
you could provide such a file so that we'll be able
to test it, it would be really great.

>

Thanks,
Dmitry

>

"John Dhom" <a@b.c> wrote in message news:c4umdb$tih$1@is.intellij.net...

Rebooted (maybe forgot to)... current status as follows...

>

2 Exceptions on Solution load (400 error trying to web submit)
GetFullPathHelper()... new, for me, .75 build
exception trying to reference unloaded app domain... same as .73

>

"Loading Assemblies" still pretty slow

>

ReBuild solution... I'm getting a "Loading Assemblies" for each project

in

the solution. Never noticed this before. Is this new to .75?

>

.73 comment... VS.NET freezes fairly often. This is true for both medium
forms based files (bunch of InitializeComponent() stuff), say avg 1500
lines. This is true for small to medium size class files as well, say
200-500 lines.

>

I'm running a default ReSharper config. After reviewing the forum I see

a

number of comment about turning off syntax highlighting in regard to

vs.net

lockup (where vs.net is consuming 96%+ cpu). Guess I'll turn it off and

see

if it helps.

>

Oh yeah, can someone please comment on my older thread titled "Font Size
Trauma"?

>

/jhd

>

"Nat" <no_mail@jetbrains.com> wrote in message
news:26576385.1081167665809.JavaMail.itn@is.intellij.net...

Hi,

>

I think your fix in 1556 should do the trick. I figured out that #75

installer removed HKCR/TypeLib/{49A1950E-3E35-4595-8CB9-920C64C44D67}

which

pointing to VSLangProj.tlb

>
>

>
>





Attachment(s):
vsLockUp.75.JPG
0
Comment actions Permalink

Hello Darren,

Looks like build 76 finally fixed the installer, yey!!!

-Michael

Been using various builds of Resharper and so far been really
impressed. Tried installing 75 over 73 today, the install failed -
one of the components appeared to fail registration and rolled back.
So I removed 73 and re-installed. This time appeared to work. When I
started VS.NET with any of my solutions Resharper through an
exception. I've sent the stack trace using the automated tool.

However I then started VS.NET and it claimed that Resharper had
problems would I like to remove the add-in. I said yes and then
de-installed. Now the deinstall and install fails, claiming some
issue with the Extensibility assembly. This also seems to have
screwed all of my addins (NUnitAddIn and QuickCode). NUnitAddin now
complains that it can't find the assembly 'Office'.

Has Resharper removed a shared assembly?

I've attempted to remove all add-ins and re-install to no affect.

I'm currently in the process of repairing the VS.NET 2003 installation
in the hope that this resolves the problem.

Darren


0
Comment actions Permalink

Still have the issue in #76

System.NullReferenceException: Object reference not set to an instance of an object.
at ReSharper.FindResults.FindResultsPanel.Initialize() in C:\temp\tmpA848.tmp\src\ReSharper\windows\FindResults\FindResultsPanel.cs:line 383
at ReSharper.VSUIManager.Init(IComponentContainer container) in C:\temp\tmpA848.tmp\src\ReSharper\VSUIManager.cs:line 210
at Component.ComponentContainer.InitializeComponent(IComponent component) in C:\temp\tmpA848.tmp\src\Services\component\impl\ComponentContainer.cs:line 136

System.NullReferenceException: Object reference not set to an instance of an object.
at ProjectModel.VS.VSProjectManager.Init(IComponentContainer container) in C:\temp\tmpA848.tmp\src\Services\project\vsImpl\VSProjectManager.cs:line 680

0

Please sign in to leave a comment.