0

I have had a persistent problem with Visual Studio 2010 and any framework version reporting this error, after adding a test project:

"Assembly Not Available in the Currently Targeted Framework"

So far, I have had this happen with only two assemblies, and always consistently:

  • System.ServiceProcess
  • System.Configuration.Install

The problem is that the project file does not identify a specific framework version for these references, showing version 0.0.0.0 in the properties. I can work around this by manually altering the project file to include <SpecificVersion>True</SpecificVersion> in the reference element.

This is a problem, because I am unable to Mole types that inherit or implement these problematic assemblies. The issue is that Pex and Moles generate their own project files, which are also broken, during the build process. There is no opportunity to manually fix these, and I think it's just stupid to have to build a workaround using ICorProfilerCallback.JITCompilationFinished to get anything to compile.

So, does anyone else have this issue? I have already re-installed VS2010. I don't see any fix for this.

I have most certainly researched this, and have been working around it all year. I'm getting rather annoyed by this, and think something has simply gone wrong or I don't understand that this is intended behavior (I can't imagine why...).

Mike Christian
  • 1,526
  • 1
  • 15
  • 27
  • What is your target .NET version for this project? – Andrey Agibalov Aug 17 '11 at 17:20
  • t doesn't matter what framework version I select. The problem is the .csproj file is not being built correctly. =/ – Mike Christian Aug 17 '11 at 17:21
  • 1
    Define "not being built correctly". Most likely is that you have "client profile" selected in you target version vs. normal .NET version. – Andrey Agibalov Aug 17 '11 at 17:23
  • These assemblies exist in both client or full profiles. My project is set to full. This issue occurs in both profiles, in both 4.0 and 3.5. – Mike Christian Aug 17 '11 at 17:36
  • @ loki2302: "Not being built correctly" refers to the references for these two assemblies showing version 0.0.0.0 unless I manually adjust the .csproj file. Manual intervention means "not built correctly" to me. You should know that the project itself runs file, but I am unable to add a test project. That's important when using TDD. ;) – Mike Christian Aug 17 '11 at 17:46
  • Strange problem and impossible to repro. It certainly can't be a client profile related problem. I can only guess that previous manual editing of the .csproj could have broken something. – Hans Passant Aug 17 '11 at 18:39
  • Funny you should mention that... I never had any problems with these assemblies, until I ran Pex on a Windows Service solution. This has been a persistent issue, ever since. I still suspect Pex has adversely altered something that plays a part in generating project files. I wish I could tell you how to reproduce it, otherwise. =| – Mike Christian Aug 18 '11 at 16:46

3 Answers3

1

Go into project properties and change the Target Framework to .NET Framework 4. I'm guessing you're using a project type whose default is .NET Framework 4 Client Profile. (like console app, for example)

heisenberg
  • 9,665
  • 1
  • 30
  • 38
  • It doesn't matter what framework version I select. The problem is the .csproj file is not being built correctly. =/ – Mike Christian Aug 17 '11 at 17:21
  • Ok, I guess I'd have to see the code but given the error message and situation that you've laid out its hard to imagine that this isn't a problem with the target framework setting. I know referencing ServiceProcess for me will give the same behaviour you're describing if you are targeting the Client Profile but apparently you've found something else that causes it as well. – heisenberg Aug 17 '11 at 17:26
  • Agreed. I have been building several Windows Service applications, to facilitate seamless platform migration to Microsoft technology. These services import data to SQL Server, and automate other functions to synchronize the systems, until migration is complete. This has definitely been an annoyance. My solution has been to extract all logic from the class inheriting ServiceBase to one that does not. – Mike Christian Aug 17 '11 at 17:39
0

Visual Studio 2010 generated the following reference elements, in the .csproj files:

<Reference Include="System.Configuration.Install" />
<Reference Include="System.ServiceProcess" />

To correct the problem, the XML must be modified, to:

<Reference Include="System.Configuration.Install">
    <SpecificVersion>True</SpecificVersion>
</Reference>
<Reference Include="System.ServiceProcess">
    <SpecificVersion>True</SpecificVersion>
</Reference>
Mike Christian
  • 1,526
  • 1
  • 15
  • 27
0

I'm having exactly the same problem with Visual Studio suddenly being unable to reference these assemblies: System.ServiceProcess System.Configuration.Install

The only way to fix it is to re-install Visual Studio 2010 and abandon all hope of using Moles until it's fixed.

Paul
  • 1
  • 1
    thank you for your answer. I have tried a complete un-install and fresh installation of VS2010. Oddly, this happens on both my day job workjstation and on my own laptop and desktop machines. – Mike Christian Dec 30 '11 at 21:28