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.
Related
I have a .Net standard 2.0 project in a Visual Studio solution that contains some Azure functions. In the same solution, I've created a .Net Core 2.0 Unit Test project. I've added a project reference from the .Net Core Unit Test project to the .Net standard 2.0 library.
Despite the project reference, Visual Studio is behaving like I'm referencing a dll instead of the project. For example, if I try to use F12/Go to reference, it brings me to a 'From metadata' file instead of the actual code file in the other project. Additionally, codelens features like 'Tested by' (and even just 'referenced by') and the Live Unit testing icons in the .Net Standard project aren't working, since they don't seem to be aware of the Unit Test project at all.
Is there some way to get this integration working between the two projects? My Visual Studio is up to date (15.5.3 enterprise), and I'm not using any tools like Resharper or anything like that.
I'm also facing the same issue but so far the project reference vs dll reference is not the case. I believe this is an existing issue with Azure function projects. There is a thread in Microsoft community regarding this issue. The last comment from Visual Studio is as follows:
I'm closing this report, because in the last 90 days there was no internal developer activity and very small number of new votes or comments. Sorry, we would like to look at this further, but we just don’t have the time right now. Our goal in closing older issues such as this one is to keep customers informed on which issues are currently being pursued by Visual Studio teams. If you still have trouble with our latest version, please report it as a new problem.
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.
I'm trying to move my VS 2008 solution to VS 2010. Everything works perfectly (compile and link) if I keep the target framework at 4.0.
When I change the framework 2.0 and change the platform framework v100 (to get past compile errors) only to run into metadata linking errors, like this one:
error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000f7). C:\Development\Main\Filemaster\SoxService\MSVCMRTD.lib(managdeh.obj)
I've read that I'm supposed to use ILDAsm but it doesn't like my obj file and since the link didn't complete I don't have an exe to load.
Can anyone please provide some advice on how to find the sorts of errors?
I hate nothing worse than fighting the tool!
I was able to get around this problem by going into the project XML file itself and changing the TargetFramework to be 4.0 After that everything compiled and linked fine.
Hans he is referring to C++ Native Multi-Targeting which can be found at this location Platform Framework can be changed under project Properties > General and is advised by the article - however this does not work due to apparent bugs in VC++
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.
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