According to this feature matrix, Visual Studio 2010 Premium (RC) includes "static code analysis".
However, adding calls to Contract.Requires at the start of my methods doesn't seem to have any effect. I don't get runtime exceptions if the contract is violated. I don't get compiler warnings if a contract cannot be proven. I also can't find a "Code Contracts" tab in the project settings.
Am I missing something obvious or is this feature only available in the Ultimate edition?
There does indeed seem to be some confusion about whether or not Code Contracts is included in the framework that comes with beta 2 of VS2010, or even in VS2010 itself. The Code Contracts forum (and expecially this post) has several mentions of this with no answers as of yet.
I don't think that Code Contracts falls under the heading of static code analysis. I think static code analysis refers to other code analysis tools like FxCop.
I have tried using Contract.Requires in VS2010 beta 2 ultimate edition, but I get the same behaviour as you. If you look in the project properties under the Code Analysis tab, you can enable code analysis, but this doesn't relate to Code Contracts.
According to the comment by Melitta (from the Base Class Libraries Team) on the connect article Make data contract static checking available in Professional Edition:
...but the restriction on the static analysis tool stands for this upcoming release. It keeps the code analysis story consistent, in that the static analysis tools require VSTS.
This suggests that you (will) have to have the team system version to get the compile-time version of Code Contracts.
To get static analysis in Beta 2 you have to download and install the Code Contracts bits (1.2.21023.14 or higher) from MSDN DevLabs. Then under the project properties, there will now be a Code Contracts tab... from here you can turn on static analysis...
The behaviour you're seeing is because the Code Contracts API is in mscorlib assembly, which allows asserts to work, but nothing else.
I'm assuming this won't be necessary by RTM.
You need to turn on the code contracts runtime checking in the project properties. If that settings pane doesn't exist then you need to install the Code Contracts download from Microsoft (despite the fact that the Contract.Requires exists in the framework).
Only the runtime checking is available in the Professional editions.
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.
I have a solution in Visual Studio 2013 (c# code) that has a reference to a third-party assembly that I added with NuGet (ICSharpCode.SharpZipLib). When I run the "Code Analysis" on the solution I get lots of warnings coming from the third-party assembly. How do I tell VS that I only want code analysis advice from my code?
I'm pretty sure the errors are coming from the library itself and not my usage of it. There are a total of 32 issues e.g.
CA2237: Mark ISerializable types with SerializableAttribute.
I am using ILMerge to bundle into a single executable do you think that has confused the code analysis?
There is no way to tell FxCop to ignore namespaces or types in your code if it lives in the same binaries. When using ILMerge, the SharpZipLib essentially becomes part of your code, as it's merged into your assembly.
To get proper results, run FxCop on the assembly that's generated before the merge.
Other solutions will mention to put a [GeneratedCode] attribute on classes you want excluded, but IlMerge has no option to to that while merging, so that won't help you out.
In Visual Studio 2015 Code Analysis works on the source code using the new Roslyn Engine, which will solve the issue probably, as it does the analysis even before compilation and as such will not be impacted by your use of IlMerge.
I currently develop C++ and C# applications with VS2008.
I have the need to have the IDE as well on our target demonstrator platform to debug and fix etc.
Could I use the Express editions for that task or are there any major drawbacks?
Any experience is welcome, also for VS2010.
You would only have to tweak things in order to compile for 64 bit (true only for 2008, that's easy in 2010), but no major functional drawback, except as Binary Worrier says it can be frustrating
However it is commonly accepted to have the full IDE on a target demo platform without buying another license, so why not deploying full IDE on it?
From About Licensing
Developer Tools – per user license
You must acquire a license for each
user you permit to access or use the
software. You may install any number
of copies on any number of devices for
access and use by one user to design,
develop, test and demonstrate
programs. Only licensed users may
access the software.
I normally don't like to just post links as answers, but this Wikipedia Article covers the differences in depth.
I've personally found coming down from the full- to the express-editions painful and limiting, you're forever "bumping your head" off some limitation or missing feature, very frustrating.
I use vs2008 at the buro and vs2008 c# excpess at home.
the limitations i come across were
c# express doesn-t like solution folders containing projects and cannot load other project types (ie setup-projects, mstest projects).
i had no painful and limiting experience yet because i use nunit instead of mstest and only ms-databases. express has advanced options (disabled by default) that give you the debug/release build feature.
by the way you donot need a visual studio to debug dotnet-applications. the dotnet-sdk has a gui debugger that can do the job but it is not as comfortable as vs. to rebuild you can use msbuild.
I have installed VS 2010 and want to migrate all code written in VS 2005 to VS 2010.
Please note that we do not have VS 2008, all code are in C# 2.0 and Asp.net 2.0 only.
Can anyone please tell me now what all points need to be considered while migrating.
Update:
I have set target framework to 2.0 for all of my Libraries and web projects. It complies without any error!
However, when site opens in IE (Set to default.aspx), it gives me error as below:
InternalXmlHelper.vb(9) : error BC30560: 'ExtensionAttribute' is
ambiguous in the namespace 'System.Runtime.CompilerServices'.
<Global.System.Runtime.CompilerServices.ExtensionAttribute()> _
Keep all the target framework settings to .NET 2.0. This way, there should be no compilation problem at all.
The changes that you should see are the solution and project files only.
Start with known good solutions in source control (and label—you shouldn't need to go back, but easy to add an extra safety net).
Open each solution in VS2010, allow the conversion wizard to do the conversion.
Resolve any issues.
Honestly, if you're just upgrading VS 2010 you don't really need to consider much. Just keep backups (any real SCM product will do) and you're good. You don't have to upgrade your applications' runtime targets at all if you don't want to.
If you're building with CAS policy, you might run into issues with using MSBuild 4.0 to build you 2.0 applications. If you don't know what I'm talking about, never mind.
My advice is to make sure everyone's "checked in" to your source code provider, and run the conversion wizard and see how it goes.
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.