VS2010 target .net 2.0 and System.Runtime.Serialization - visual-studio-2010

Why can't I add a reference to System.Runtime.Serialization when targeting .net 2.0?
Also if I convert a vs2005 project using System.Runtime.Serialization the vs2010 conversion fails with a build error.
I'm using the DataContract class and the compiler says
The type or namespace name 'DataContract' could not be found (are you missing a using directive or an assembly reference?) C:\Users\my\ClassLibrary1\Class1.cs 8 6 ClassLibrary1

The reason for this is that you need to be using .NET 3.5 to use DataContracts, they are items that were introduced with .NET 3.5 therefore you must target that version.
Here is an MSDN article that talks about one aspect of DataContracts and .NET version.

Related

How do I reference System.Windows 5.0.5 assembly (Silverlight) from .NET 4.5 library project?

I have a project written for Silverlight 5, which references Silverlight's System.Windows assembly in version 5.0.5.
Now I want to create a unit test project for it using a usual .NET 4.5 library project. When I try to add a reference to the System.Windows assembly 5.0.5 from Silverlight (using the browse dialog), Visual Studio adds the version from .NET 4.5.
Hence the version number does not match.
Why does Visual Studio behave this way?
How do I fix this?
You can reference Silverlight assemblies from a .Net project, but once you have managed to add one, you will likely have problems with dependencies on other libraries.
It will be easier on you if you to try a different approach...
I would suggest using the Silverlight Unit Test Framework to deal with testing your Silverlight code.
If that doesn't fit your need, perhaps Portable Class Libraries will.

Solrnet namespace not found when creating a new VS2010 console app

I am getting the following error:
"The type or namespace name 'SolrNet' could not be found (are you missing a using directive or an assembly reference?)"
I have created a new console application in VS2010 and added into program.cs the line
"using SolrNet;"
I've added the project reference to SolrNet.dll version 0.4.0.2002.
Some versions of solr require a reference to system.web but I do not want to do this and I believe this version doesn't have that as a requirement. I've used the object browser and added references to Nhibernate, Castle, Niject and all the other objects.
How can I get my console app to recognise the SolrNet dll?
In the project properties, change the Target Framework from .NET Framework 4 Client Profile to simply .NET Framework 4

Missing reference while Converting VS2008 project to VS2010 project

When i converted a VS2008 project to 2010 it shows an error message
The type name 'IComponentConnector' could not be found in the namespace 'System.Windows.Markup'. This type has been forwarded to assembly 'System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' Consider adding a reference to that assembly
and it was build when we add a reference System.Xaml. What would be the reason for need to add additional reference?
In .Net 3.5/3,0, IComponentConnector (namespace System.Windows.Markup) was part of WindowsBase.dll and it was moved in System.Xaml in .net 4.0 onwards.
It seems you are upgrading your project framework 3.5 to 4.0
The type was moved to the new assembly in .net 4?
You are changing you project to use .net 4 and it's telling you that you need this type from that assembly in .net 4.
if you target .net 3.5 you'll find you wont need to do this.
As a thumb rule, always add the namespace that is documented. The document says to use the namespace System.Windows.Markup. It worked in VS2008 probably because System.Xaml was internally using the namespace System.Windows.Markup.

IronRuby references conflict with System.Linq?

Using Visual Studio 2010, when I add the four IronRuby references to an existing project that uses Linq in several methods, the project won't compile due to not being able to find System.Linq all of a sudden. Does the IronRuby/.Net 4.0 Framework change the location of Linq or am I missing something?
Thanks,
Becky
Are you using the build for .NET 4.0?
The 3.0 build does have those overrides but they should be included in .NET 4.0.
http://ironruby.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=33305

VS2008 to VS2010 project conversion

I have a component project build in VS2008 and targeting the .NET Framework 3.5. I recently downloaded the VS2010 Beta 1 to make sure this project would convert over correctly when the time comes to switch to the new IDE. This project contains references to a couple of 3rd party dlls built against version 2.0 of the framework. I changed my project to build against the 4.0 version of the framework but when I try to build the project I get a ton of errors that looks like the compiler can't recognize the class types of those 3rd party libraries similar to what is below.
"The type or namespace name 'Data' does not exist in the namespace 'Microsoft.Practices.EnterpriseLibrary' (are you missing an assembly reference?)"
I'm trying to figure out why I can't compile. From what I have read .NET 4.0 uses a different version of the CLR. How or why would that impact my ability to have access to those types? Am I going to have to
a) Get the source code and recompile in VS2010 / .NET 4.0 and then reference that assembly or
b) Wait for project authors to do "a" above and release their assemblies targeting the 4.0 CLR? or
c) Something else because perhaps my VS2010 install is borked?
I can change the project properties to target 3.5 and everything works as I expect under the 2010 IDE.
I suspect this is because .NET 4.0 uses CLR 4.0, not 2.0. EL 4.1 will have been built against CLR 2.0, so I'm not sure I'd expect it to be found without help.
Seems like a CLR versioning issue to me.
For the current time, I will recommend b) and/or just compile to v2.0/v3.5.
Any specific feature that you want to use in v4.0?
I wanted to mark this question as answered and based on the comments and my own experiences, I think that Mehrdad is correct in the comment attached to the question and that it was a VS2010 project conversion problem.

Resources