I've been developing a C# project in Visual Studio Express 2013 and came across Code Contracts for .NET languages. Impressed by their brevity and the static analysis tool that came with them, I started using them in my code base. However, when I attempted to run my program, I was met by an error message similar to the one found in this SO thread, i.e.
...An assembly (probably "<my project>") must be
rewritten using the code contracts binary rewriter (CCRewrite) because
it is calling Contract.Requires and the CONTRACTS_FULL symbol is
defined. Remove any explicit definitions of the CONTRACTS_FULL symbol
from your project and rebuild...
Guides suggest that to fix this, I have to enable Code Contracts from my project's Properties page, but a Code Contracts Properties entry is nowhere to be found in Express.
Some MSDN forum threads seem to indicate that all the tooling for Code Contracts is included in the Express version, but the Code Contracts Properties page is not. This seems to be the case, as I was able to run my project in VSE 2013 only after enabling Code Contracts with a copy of Visual Studio 2012 Ultimate I acquired from my university before graduating.
Is there really no way to work with Code Contracts in Visual Studio Express except by modifying the project files either manually or with a paid version of Visual Studio? If this is the case, I am extremely hesitant to use them at all, since my company is unlikely to purchase VS licenses. Futhermore, it seems extremely odd that Microsoft would attempt to proliferate this new and superior verification paradigm but then restrict it to paying customers only.
You can probably use the new VS Community 2013, as long as you meet the licensing requirements:
http://www.visualstudio.com/en-us/visual-studio-community-vs
Here’s how Visual Studio Community can be used in organizations:
An
unlimited number of users within an organization can use Visual Studio
Community for the following scenarios: in a classroom learning
environment, for academic research, or for contributing to open source
projects.
For all other usage scenarios: In non-enterprise
organizations, up to 5 users can use Visual Studio Community. In
enterprise organizations (meaning those with >250 PCs or > $1 Million
US Dollars in annual revenue), no use is permitted beyond the open
source, academic research, and classroom learning environment
scenarios described above.
It's basically VS 2013 Professional for free so you can install the code contracts extension.
The problem is your edition of Visual Studio. You are running Visual Studio 2013 Express edition, as you stated. In order to use the binary re-writer from within Visual Studio, you need to install the Code Contracts extensions. These you can download from Microsoft's Research in Software Engineering (RiSE) site, which is packaged as a Windows Installer.
The installer installs the binary re-writer that is required, as well as a bunch of Visual Studio extensions. Unfortunately, Code Contracts states in their manual on page 40 that they don't support the various Visual Studio Express editions. You'll need to at least have Visual Studio 2013 Professional edition in order to use the Code Contracts binary re-writer extension from within Visual Studio, and in order to see the Code Contracts tab on the project properties window.
Code Contracts performs assembly re-writing as a post-build step. Meaning, Visual Studio first compiles the .NET code as it normally would. But, when using Code Contracts and enabling the right options on your project (assuming the VS extensions are installed—which you can't do in Express editions), then the binary re-writer is called for you by Visual Studio after the normal compilation process.
Instead, after compiling your program, you'll need to manually run the ccrewrite program installed by Code Contracts on the compiled assembly (and all dependent assemblies) to 're-write' your assemblies, which will add in all the Code Contract checking information. See the Code Contracts documentation (also available on the RiSE website) for information on how to do this.
Contracts are supposed to be useless for Visual Studio Express 2013 (at least Code Contracts come with a plugin for all non-express versions).
So one has to define the symbol CONTRACTS_FULL in project properties -> build -> general -> conditional compilation symbols.
And then add the proper call to ccrewrite.exe to the post-build event command line found under project properties -> build events. The command should be set to something like
"C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite.exe" -throwOnFailure "$(TargetPath)"
I successfully used this tonight with NUnit. Using contracts, my unit tests don't need to check for post conditions explicitly.
Related
I am working on developing an asp.net mvc web application , using visual studio 2012 professional. now when I want to update my project, for example by adding new features, I do the following steps:-
I copy the project folder.
past it inside a "versioning" folder.
work on the original project , were I add the new features and code.
now if I want to revert my project back before the new features, I can open the folder inside the "Versioning" folder. and so on...
now my current approach is some how sufficient.. but I am trying to find a more automated approach where I can for example revert certain file let say a certain .cs file to its previous version , or revert back my whole project to certain point.
so can anyone advice how Visual studio 2012 can help me in managing my versioning ?
Thanks in advance for any help.
Regards
You'll want to use a version control system like Team Foundation Server (TFS), Git, Mercurial, Subversion, etc. I personally recommend Git. Many of them have a means of integration with Visual Studio 2012 (for example, see How to Connect Visual Studio 2012 with git (github)?). Version control software supports features such as tracking file changes, creating code branches, merging code from different commits/users back together, etc.
Here's what a very simple workflow might look like with version control (see https://guides.github.com/introduction/flow/ for an example of the GitHub flow):
You're ready to add a new feature/start a new version. For simplicity we'll assume you're working on a single branch (e.g. Git "master" branch).
As you program, you make incremental changes to you source code and commit those changes regularly. Each commit gives you a snapshot of the work you've done and you can go back to any commit at any point and compare the changes between commits. The VCS you choose will influence how you synchronize those changes with a central/remote repository. You can even check revision history and look at previous versions of specific files and your code is typically backed up on another server for you without much additional work.
When you're ready to release, you could tag a specific revision (or merge features branches into master, or ... etc.). Whatever the case, you can keep track of all the cumulative changes you've made for each release and be able to revert back to any point.
There are a few other steps you may consider for versioning such as updating the assembly information. In the AssemblyInfo.cs file there is assembly metadata specifying the assembly version, file version (or informational version, which I prefer). See What is AssemblyInfo.cs used for?. You can configure Visual Studio to auto-increment the version numbers.
Team Foundation Server should be available by default with VS 2012, although I'm vague on the details of setting up a TFS server to host your repositories. Visual Studio added direct support for Git (open source, very popular) starting in VS 2013, however there is an extension available for 2012 (https://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c). The extension allows you to perform some of the most used Git functions such as committing, branching, and pushing.
Here are some links to get you started:
Why should I use version control?
Using Git with Visual Studio
https://git-scm.com/download/win
https://tortoisegit.org/
https://www.visualstudio.com/en-us/products/tfs-overview-vs.aspx
I use VSTS and it is fantastic. You can use GIT or TFS version control. Both are hosted by Microsoft. I prefer Microsoft due to the idea of long term support and reliability. You can see they are supporting VS 2008 to current.
https://www.visualstudio.com/team-services/pricing/
It is also free for up to 5 users.
From the link posted below.
It has full support for many versions of Visual Studio
Q: Which versions of Visual Studio can I use with Visual Studio Team Services?
A: You can use:
Visual Studio "15"
Visual Studio 2015
Visual Studio 2013
Visual Studio 2012
Visual Studio 2010, requires Service Pack 1 and KB2662296
Visual Studio 2008 SP1, requires GDR update To connect to Team
Services with
Visual Studio 2008 through 2012
Start Visual Studio.
From the Team menu or Team Explorer, go to Connect to Team Foundation Server > Select Team Projects > Servers.
Add your Team Services account ({youraccount}.visualstudio.com).
Select your team project, and finish connecting.
If you get connection errors, try choosing HTTPS as your protocol.
https://www.visualstudio.com/en-us/docs/setup-admin/team-services/connect-to-visual-studio-team-services
GIT Vs TFS Version Control - https://www.visualstudio.com/en-us/docs/tfvc/comparison-git-tfvc
One thing to look into is how you visualize editing and checking in code. I personally find that TFS version control follows a very simple and linear model. I prefer it to git. But its really Apples vs Oranges and usually people like what they are used to. I will say that Git currently is in active development and is not as feature rich as TFS-VC. Not to mention VSTS hooks into their entire ecosystem of plugins, build systems, test infrastructure and all of their cloud platform "Azure"
If you dont need to be sharing your version controlled stuff, I like TurtleSVN. Its simple and I like the UI it has for displaying modifications between versions. It adds a choice on the right-click menu of any file or folder in windows explorer for "TurtleSVN" and then all of the operations can be handled from there.
My Suggestion is still using TFS - I my project which is a product ( ASP.MVC application ) - we are using following structure in TFS..
we have a main branch - DEV branch a QA branch and a SP branch. See screen shot attached)
Main Branch - Where all the code is merged using scripts - before we start with new version of development and then a new DEV branch with version is created from this main branch.. - so we have track of every version and new features added to each version... and For new client the code from Main branch is given.
Dev - Based on features added we create different folder for each new set of features / enhancements and put the version.
SP - After development is completed - the DEV branch is freeze and we create a new branch id SP and deploy the code for QA team - any defect founs are fixed in SP and deployed to QA - once testing is done the code is SP is freeze with QA approved and deployed to main and provided to Clients..
Finally using script - every thing from SP is merged in to Main.. and for new development - a new Branch in DEV is created from the Main..
This way we have track of enhancements / feature for each DEV phase and related SP is available and our product is getting developed in Main.
Hope this Helps..
In short: I need to open an application originally built in Visual Studio 2008 (version 9) in Visual Studio 2013 without upgrading the project since the overall project architecture must remain the same for when I check it back into source control.
Details: I need to open a Visual Studio solution (.sln) inside Visual Studio 2013. The solution in question was originally developed in Visual Studio 2008, so when I try to open said solution in Visual Studio 2013, I am shown a prompt with the projects within the solution checkmarked, with the message:
These projects are either or supported or need project behavior impacting modifications to open in this version of Visual Studio. Projects no displayed either require no changes or will automatically be modified such that behavior is not impacted. Visual Studio will automatically make functional changes to the following projects in order to open them. You will not be able to open these projects in the version of Visual Studio in which they were originally created.*
My attempt at a fix was to just upgrade the solution and hope for the best. This is successful, but after building and attempting to run the main project, I see the following build error:
The type 'Microsoft.Web.Services3.WebServicesClientProtocol' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. *
I then tried both commenting out the references to this assembly and adding in the missing reference. Okay, so then I rebuilt the solution and attempted to run. Same error, but for a different assembly. Repeat fix, same error for different assembly. This pattern continues and continues, and at this point I realize this is unacceptable anyway, because when I make a change to this solution, I need to check it back into source control. When others open it, they may be opening it in VS2008, and therefore this “upgraded” version is inconsistent with the version the business uses. I need to open the solution originally build in VS2008 in VS 2013 (can't work around this, needs to be VS2013). If it helps, I'm using 64 bit Visual Studio 2013 Ultimate.
Any help or guidance will be greatly appreciated!
As several of the commenters have already helpfully pointed out, this is not possible. Round-tripping (i.e., opening and manipulating project files created by an older version of Visual Studio in a newer version of Visual Studio) was not supported until Visual Studio 11. The only way to open a Visual Studio 2008 project/solution in a later version of Visual Studio will be to convert it.
As far as interoperability with previous versions is concerned, you have two options:
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then edit the code files. Once you're satisfied with your edits, commit only the modified source files, not the project infrastructure files. Your fellow developers, stuck on VS 2008, won't notice any difference.
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then rename the project file (e.g., by appending a -vs2013 suffix to it). Commit this to your code repository. You will now have two project files in your root directory, one for each version of Visual Studio that your team works with. From here on, you just open the project file corresponding to the version of VS that you have installed.
I used approach #1 for a good part of last year, where I spent most of my time developing a C++ application in VS 2010 on a desktop machine, but also wanted to work on it on my notebook running VS 2013. Of course, in my case, it took a trivial amount of time for the automatic conversion to upgrade my project file after pulling from source control. I didn't have to do any tweaking thereafter to get the project to build. It sounds like your case is different, so option #2 might be a better choice.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As a long-time Visual SourceSafe user (and hater) I was discussing switching to SVN with a colleague; he suggested using Git instead. Since, apparently, it can be used as peer-to-peer without a central server (we are a 3-developer team).
I have not been able to find anything about tools that integrate Git with Visual Studio, though - does such a thing exist?
What are the technologies available for using Git with Visual Studio? And what do I need to know about how they differ before I begin?
In Jan 2013, Microsoft announced that they are adding full Git support into all their ALM products. They have published a plugin for Visual Studio 2012 that adds Git source control integration.
Alternatively, there is a project called Git Extensions that includes add-ins for Visual Studio 2005, 2008, 2010 and 2012, as well as Windows Explorer integration. It's regularly updated and having used it on a couple of projects, I've found it very useful.
Another option is Git Source Control Provider.
I use Git with Visual Studio for my port of Protocol Buffers to C#. I don't use the GUI - I just keep a command line open as well as Visual Studio.
For the most part it's fine - the only problem is when you want to rename a file. Both Git and Visual Studio would rather that they were the one to rename it. I think that renaming it in Visual Studio is the way to go though - just be careful what you do at the Git side afterwards. Although this has been a bit of a pain in the past, I've heard that it actually should be pretty seamless on the Git side, because it can notice that the contents will be mostly the same. (Not entirely the same, usually - you tend to rename a file when you're renaming the class, IME.)
But basically - yes, it works fine. I'm a Git newbie, but I can get it to do everything I need it to. Make sure you have a git ignore file for bin and obj, and *.user.
Git Source Control Provider is new plug-in that integrates Git with Visual Studio.
I've looked into this a bit at work (both with Subversion and Git). Visual Studio actually has a source control integration API to allow you to integrate third-party source control solutions into Visual Studio. However, most folks don't bother with it for a couple of reasons.
The first is that the API pretty much assumes you are using a locked-checkout workflow. There are a lot of hooks in it that are either way expensive to implement, or just flat out make no sense when you are using the more modern edit-merge workflow.
The second (which is related) is that when you are using the edit-merge workflow that both Subversion and Git encourage, you don't really need Visual Studio integration. The main killer thing about SourceSafe's integration with Visual Studio is that you (and the editor) can tell at a glance which files you own, which must be checked out before you can edit, and which you cannot check out even if you want to. Then it can help you do whatever revision-control voodoo you need to do when you want to edit a file. None of that is even part of a typical Git workflow.
When you are using Git (or SVN typically), your revision-control interactions all take place either before your development session, or after it (once you have everything working and tested). At that point it really isn't too much of a pain to use a different tool. You aren't constantly having to switch back and forth.
I find that Git, working on whole trees as it does, benefits less from IDE integration than source control tools that are either file based or follow a checkout-edit-commit pattern. Of course there are instances when it can be nice to click on a button to do some history examination, but I don't miss that very much.
The real must-do is to get your .gitignore file full of the things that shouldn't be in a shared repository. Mine generally contain (amongst other stuff) the following:
*.vcproj.*.user
*.ncb
*.aps
*.suo
but this is heavily C++ biased with little or no use of any class wizard style functionality.
My usage pattern is something like the following.
Code, code, code in Visual Studio.
When happy (sensible intermediate point to commit code, switch to Git, stage changes and review diffs. If anything's obviously wrong switch back to Visual Studio and fix, otherwise commit.
Any merge, branch, rebase or other fancy SCM stuff is easy to do in Git from the command prompt. Visual Studio is normally fairly happy with things changing under it, although it can sometimes need to reload some projects if you've altered the project files significantly.
I find that the usefulness of Git outweighs any minor inconvenience of not having full IDE integration but it is, to some extent, a matter of taste.
Microsoft announced Git for Visual studio 2012 (update 2) recently. I have not played around with it yet, but this video looks promising.
Here is a quick tutorial on how to use Git from Visual Studio 2012.
Also don't miss TortoiseGit...
https://tortoisegit.org/
There's a Visual Studio Tools for Git by Microsoft. It only supports Visual Studio 2012 (update 2) though.
Visual Studio 2013 natively supports Git.
See the official announcement.
The Git support done by Microsoft in Visual Studio is just good enough for basic work (commit/fetch/merge and push). My advice is just to avoid it...
I highly prefer GitExtensions (or in less proportion SourceTree). Because seeing the DAG is for me really important to understand how Git works. And you are a lot more aware of what the other contributors to your project have done!
In Visual Studio, you can't quickly see the diff between files or commit, nor (add to the index) and commit only part of modifications. Browse your history is not good either... All that ending in a painful experience!
And, for example, GitExtensions is bundled with interesting plugins: background fetch, GitFlow,... and now, continuous integration!
For the users of Visual Studio 2015, Git is taking shape if you install the GitHub extension. But an external tool is still better ;-)
TortoiseGit has matured and I recommend it especially if you have used TortoiseSVN.
The newest release of Git Extensions supports Visual Studio 2010 now (along with Visual Studio 2008 and Visual Studio 2005).
I found it to be fairly easy to use with Visual Studio 2008 and the interface seems to be the same in Visual Studio 2010.
The simplest solution that actually works quite well is to add the TortoiseGit commands as external tools.
Solution to adding a Git (TortoiseGit) toolbar to Visual Studio
As mantioned by Jon Rimmer, you can use GitExtensions. GitExtensions does work in Visual Studio 2005 and Visual Studio 2008, it also does work in Visual Studio 2010 if you manually copy and config the .Addin file.
Currently there are 2 options for Git Source Control in Visual Studio (2010 and 12):
Git Source Control Provider
Microsoft Git Provider
I have tried both and have found 1st one to be more mature, and has more features. For instance it plays nicely with both tortoise git and git extensions, and even exposed their features.
Note: Whichever extension you use, make sure that you enable it from Tools -> Options -> Source control -> Plugin Selection for it to work.
As of 2013-02-11, the Microsoft Git plugin for Visual Studio 2012 should work with the Express version as well.
I remember seeing an open source project within the last year that I was able to open in both VS 2008 and VS 2010 without an upgrade wizard popping up. I think...
Is it possible to create a project/solution that will open up in any version of Visual Studio without prompting me to run the upgrade wizard? If so, how do I do this?
Information for both C++ and C# projects would be most helpful.
You can, use CMake and generate VSx solution.
I think the project that you have seen had 2 visual studio solutions for different visual studio versions.
Update:
Also, you can use http://sourceforge.net/projects/vspc/
or see http://www.emmet-gray.com/Articles/ProjectConverter.htm
The solution format hasn't changed significantly over the visual studio versions except the version number.
If the code itself is generic enough (not using linq, etc) then you can edit the first line of the solution file to "downgrade" the version.
VS2005 uses:
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
You can give the Prebuild project a try to generate needed solution files on the fly.
Prebuild is a cross-platform XML-driven pre-build tool which allows
developers to easily generate project files for major IDE's and .NET
development tools including: Visual Studio .NET 2002, 2003, 2005, 2008, 2010
SharpDevelop, MonoDevelop, NAnt and Autotools.
May be it is not what you ask about, but you can convert you project into nmake target
The only way to do this is to create separate solutions (for 2010 and 2008), and include existing projects to different solutions. Create new projects in VS2008, and then add them to VS2010 solution.
You may need something like round-tripping
Round-tripping is the ability to use a current or previous version of Visual Studio to target a platform that is supported by both versions of VS. For example, with round-tripping, you can open projects from a previous version of VS in a newer IDE without the need for conversion, thus allowing you to work side-by-side on old and upgraded projects.
Read more
I downloaded the team explorer 2005 and when I tried to open the application from source control , I am getting the error .csproj applicaion type is not installed.
How can I resolve this ?
In order to open a .csproj you will need to install a version of Visual Studio that supports .csproj`s. There are free versions, called express SKU's, of Visual Studio that should help you out here. It, and the other express SKU's, are available at the following link
http://www.microsoft.com/express/Windows/
You need a CAL (Client Access License) to run just team explorer and access the TFS functionality to check in and check out and other things. If you're wanting to open the projects and make changes you'll need a license for visual studio. There are many different options there. I don't believe you can use the free one in your situation. Using VS professional you'll still need to get the CAL as well to access TFS but if you get one of the team editions of VS you will have the TFS CAL included.
That's how I understand the licensing for TFS/VS but I'm not an expert and it would probably be best to ask your supplier or microsoft about licensing.
I believe Team Explorer allows one to interface with TFS which includes accessing project documentation, filing bugs, and possibly retrieving source code. However, I believe you need Visual Studio to open up project/solution files (i.e. a developer task).
This might be different with Visual Studio 2010 but that's the sales pitch we heard regarding 2008.
In summary, although you need the specific module that loads C# projects. When you installed Team Explorer, although you have the basic IDE, that module is not loaded (is similar to when you install SQL Server client - you have the Visual Studio IDE, but the only module loaded is the SQL Server management Studio). As some of the other guys suggested, try to install Visual Studio C# Express (you can find more information here - http://www.microsoft.com/express/Windows/ - click on Microsoft® Visual C#® 2008 Express Edition). Notice that later on if you want to use web application, you will need to install the web edition and so forth.
When you install Visual Studio Professional (or Team Suite) most of those modules are installed by default.
I hope this info helps.