views:

73

answers:

2

Hi, my issue is very similar to:

http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-vb/54944/VB-Net-project-throwing-errors-when-executing-Clean-Solution

  1. Typical errors: Unable to load referenced library X
  2. Type IWshRuntimeLibrary.WshShell is not defined.
  3. Interface System.IDisposable is not implemented by this class.
  4. Namespace of type specified in the Imports Z does not contain any public members or cannot be found. Make sure the imported element name does not use any aliases.

This must have to do with a VB.net project configuration. Currently there is a setting "Treat all warnings as errors". I would like to keep that setting, but also resolve these annoying "errors".

+1  A: 

I've experienced a similar problem and fixed it by running the following command in the VS command line tool

devenv /resetskippkgs
Laplace
Would you elaborate please? Is there a way to set this flag through GUI IDE? What does it do?
Hamish Grubijan
From MSDN: "Clears all options to skip loading added to VSPackages by users wishing to avoid loading problem VSPackages, then starts Visual Studio." I'm not sure what causes the problem but that command fixes it when I start getting errors for no reason. Let me know if it works for you.
Laplace
+1  A: 

I'ev had problems executing Clean's via MSBuild in VS2008 when projects were registered for COM interop.

The problem is that the "Clean" target auto-generated for a solution cleans projects in the same order in which they were built.

This causes problems for projects registered for COM when MSBuild attempts to load and then unregister the assembly from COM during a "Clean".The issue occurs if the assembly has a dependency on another project because the dependency will be deleted first and therefore loading the assembly will fail and MSBuild will be unable to unregister it.

A workaround is to change the solution .cache file (which contains the targets auto-generated by MSBuild during "Build") and reverse the order of the "Clean" target. I hacked-together a quick-fix custom build task to do this as a post-build step.

No idea if this was fixed in VS2010 or indeed if this matches your problem since you don't give many specifics in your question ;)

Paolo