In Visual Studio 2010 project property pages, if I select Common Properties and Framework and References for a C++ project, I can see all the references from a project.
They usually have this icon:
Sometimes, though, some references appear as this:
I tried to google it or find any documentation about it in the msdn documentation about references, but cannot find anything related to this. Does someone know about this? Thank you very much in advance!
This happens also if you had VS2010 SP1 and then install .net 4.5. They changed the handling of this in a way that causes problem in VS2010. (.net 4.5 is installed with VS2012)
I believe it is because the referenced assembly is a different version than your target application. I receive the same thing if I reference a .net 4.0 assembly from a .net 3.5 project.
Related
recently I have experienced a problem which is really strange. I have a c# VS solution which contains 2 projects: a class library (.dll) and a WindowsForms. I had no issues so far to reference the dll from my WinForms applications. However, now, after I reference it, everything works fine, in terms that while writign code the dll assemblies are recognised, until I try to compile and debug, where the dll is not recognised any more, though it is referenced.
Any help would be apprecited.
Regards,
D.
PS. I have tried both referencing the project and dll...Does that mean that the problem is at the dll?
do you have correct .net target on both sides ?
.net client profile / full .net
Here's a puzzler - something that doesn't work that I assumed would (no surprise there).
We have a library project that is referenced in a few other desktop app projects. The library project is written in VS 2005 (.NET 2.0).
My problem is that some of our apps still live in VS 2005 for the time being (for various reason). I can't seem to reference this library project in VS 2010 without it demanding that I upgrade it to .NET 4, which if I do, then breaks my ability to include it as a reference in my VS 2005 projects.
This type of thing fries my brain. Is there any way I can make this work?
Hmm, that doesn't make a lot of sense. You don't reference a 'library project', you reference the DLL that it produces. Project + Add Reference, Browse tab. There's no known problem with that, within a 95% accuracy guess, mixed mode assemblies have a few hairs.
If you actually try to load a vs2005 project into a vs2010 solution, then yes, it's going to try to convert the project file. And that turns vs2005 catatonic, it doesn't have the time machine to guess what a vs2010 project looks like. Just making a copy of the project directory solves that problem.
Can you change the .NET version back to 3.5 or 2.0 in VS.NET 2010 after it revises the project version to .NET 4.0?
Use a file reference to the built dll, rather than a project reference.
You may also find you need to add an extra bit of compatible-framework info to your manifest file to tell .net to allow your .exe to use .net 4 and .net 2 assemblies alongside each other - if it's not there you'll just get an error on startup. (Sorry, I can't remember the exact details and I'm not at my work machine right now to be able to find them - but if you have problems at runtime, the error message should lead you to the exact solution you need)
Correction: I was thinking of this 'useLegacy' startup setting, which you may need to add to your app.config if you want to use a mixture of .net 2.0 and .net 4.0 assemblies in your application:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
On option, that is a complete PITA, but should work is:
Create a new project file in 2010 that includes everything the 2005 project file has. Just call it MyProject2010.csproj or whatever.
Then, add this project to your 2010 solution.
I've loaded a WPF project initially created in Visual Studio 2008 into Visual Studio 2010. The conversion process goes smoothly, but on certain XAML files the VS2010 designer throws several errors related to project references, including this one:
System.Reflection.Adds.UnresolvedAssemblyException
Type universe cannot resolve assembly: GalaSoft.MvvmLight, Version=3.0.0.31869, Culture=neutral, PublicKeyToken=3e875cdb3903c512.
This assembly reference works just fine in the Expression Blend 4 designer, but not in VS2010.
I can build and run the solution successfully.
My solution targets the .Net Framework 3.5 SP1.
I can't quite tell if you're having the same problem I had or not, but I was getting that type universe error all the time with the Ninject .dll. I solved it by "Unblocking" the zip file before extracting it. I think this only affects Vista and Win 7 dev machines but it's worth a try. I posted a blog entry last week with details on the error and the solution. Scroll down to the "Foiled by a Blockhead" section.
Check which version of the MVVM Light assemblies you are referencing.
When you install the MVVM Light Toolkit binaries, you get separate WPF 3.5 and WPF 4 versions. You can find the WPF 4 assemblies (assuming default install location) in
c:\Program Files\Laurent Bugnion (GalaSoft)\Mvvm Light Toolkit\Binaries\WPF4
I found a workaround, but I'm not happy with it. If I change the target framework setting for the project from ".NET Framework 3.5" to ".NET Framework 4 Client Profile" the designer works just fine. But I'd rather not change my target framework just to get designer support!
When I change the target framework of any project in Visual Studio 2010 it does not actually change the System assembly references. For example if I target v2.0 and check the properties of System and System.Data I can see that they are still both v4.0. If i change the target to v3.5, System stays at v4.0 but System.Core changes to v3.5.
Because of this I am truly not targeting anything except v4.0.
There may be something strange in your install. I just created a WPF project, keeping the default settings, thus targeting .NET 4. Then, I switched to 3.5. VS asked to reload the project and then the targeted runtime of the references was v2 (correct) and their version was 3.5 (with an error that Microsoft.CSharp and System.Xaml were missing, which is understandable).
Then, I did the same for .NET 3 and 2 and got the same results: after reloading the project, the version of the referenced DLLs had changed were it made sense (System.Data is always v2.0).
When using the CLR v2, the vshost debug helper had its name changed to something like vshost-clrv2.
I've reinstalled Visual Studio several times and it hasn't solved anything. After uninstalling there is 10.0 stuff laying all over the place leading me to believe the uninstaller is also leaving what ever is causing this issue. I'm going to have to reinstall the OS to get the issue to go away.
I also wanted to link to my earlier post because this post has more information about how I originally discovered this issue, contains a link to the Microsoft Connect bug report I opened and links to several other users experiencing the same problem: Visual Studio 2010 Can no longer build .NET v3.5
Duplicate: Why are C# collection-properties not flagged as obsolete when calling properties on them?
I just migrated a .NET 1.1 project to .NET 2.0 using Visual Studio 2008. I know that there are references to obsolete methods in the project.
But Visual Studio does not show "obsolete"-warnings after building. The build succeeds and shows only 3 warnings from members that are assigned a value that is never used. When I remove these members there are no warnings at all.
I NEED THESE "OBSOLETE"-WARNINGS
The Warning level is 4 (maximum), Warnings are enabled.
Just one sample:
protected internal DataConnector()
{
_connectionString = ConfigurationSettings.AppSettings["ProductConnectionString"];
}
All references that should result in an "obsolete"-warning are to members of classes of the .NET Framework.
Is the code calling the obsolete method(s) itself flagged as obsolete?
Just taking a shot in the dark here, but is the usage of an obsolete member taking place in a project that you're REFERENCING, and when you're building it isn't actually rebuilding that project? If that's a possibility, I would try manually building the project where the usage is taking place, or just rebuilding the entire solution.
Make sure you are doing a full build on the project, not just an incremental build.
Jeff Yates is right, this is a duplicate to Why are C# collection-properties not flagged as obsolete when calling properties on them?
It is a bug in the C# 3.5 compiler reported here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=417159
I checked it: copied the csc.exe commandline from the output window to a cmd-console. When I change the directory to the .NET 2.0 directory (using C# 2.0 compiler), it shows the warnings. Microsoft knows this bug and fixed it in C# 4.0 but will not fix it in the 3.5 version.