I made a search to find how am I adding an installer to my c# application. In every result I found that I need to add new file from Setup and Deployment templates, but I have no those templates. Even in online search I didn't find so.
what should I do?
The VS setup templates were removed post VS-2010.
Now, you have to use something else. "InstallShield" is still available, and Wix is a very popular install framework. You can, of course, just roll your own installer as well.
Alternatively, just use VS 2010 or earlier to create your setup/deployment projects.
I reckon you should do some research. There are many options out there depending on your type of application. Is it an executable that runs locally? Is it a Web application? Or a mobile application?
Microsoft provides lots of options/guides out of the box. Assuming you use Visual Studio 2013 check this MSDN article which is a good guide to start your research journey: https://msdn.microsoft.com/en-us/library/wtzawcsz.aspx
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.
This is for C#.
I know that I can include a COM File as a resource in my executable and then unpack it into the current directory when its needed. A com file such as LibCurlNet.
What I would like to know is if Visual C# 2010 Express provides an automated way of doing this.
Such as a simple option that I can select. I do not mean using the publisher.
I don't even think there is an automated way in Visual Studio Professional/Ultimate for doing this, let alone VS Express. You probably need to use a more manual approach, such as the one described here (but I guess you already knew that).
There is a tool for packing .NET DLL:s and native DLL:s called NETZ. Granted, I have not tried it myself, but maybe this tool can be of some help to you?
I am doing on a project to built automatic GUI testing for graphical application in .NET. I will use C# but i am trying to reading to get some ideas. But I don't have any idea on how to record and replay back. So can you give me your ideas.
Here's a blog from the visual studio team that goes over this exact topic. It's about how they tested pre-wpf and post-wpf.
This post covers an overview of techniques that we used to create and maintain automated user interface regression tests for Visual Studio. Regression tests are a type of software test that, collectively, aim to be an oracle of expected functionality for the target application, run often against new builds of product – they aim to uncover regressions in behavior introduced in a new build.
Visual Studio Blog
Selenium RC!
There is also the TFS Test that has web tests, which tie into load test. Nice platform, but if you are not already using TFS then it is not worth it.
Frankly, I don't think there is a good answer out there for this. There are two options, however, that work okay:
Visual Studio Test Edition (as durilai suggested)
Telerik's Web Testing (both a free version and a version with a cost but depending on your UI, this may or may not work)
A good (commercial) C#-based product is Ranorex, it may do what you need.
Have you updated your Visual Studio to 2010 version? It has a build-in coded-ui automated testing feature, which could be used to record and replay back the test for win form.
Selenium
Watin
are some options that come to mind
To test C# apps there are a few things we have had success with:
PowerShell
TestPlant
and possibly would be the new VSTS 2010 features, though we haven't tried them
I want to start using version control properly for my own personal projects written using Visual Studio 2008 Express Editions. I'm using both Visual C# Express Edition and Visual Web Developer Express Edition.
I'm almost always the only developer on these projects.
I've previously used Subversion with Windows Explorer integration provided by Tortoise SVN and it worked well, but obviously source control and development were two separate operations.
Is there a better version control system for my situation?
Unfortunately, the express edition does not let you use Ankh SVN, which is integrated right into the visual studio interface. I find Tortoise SVN/Subversion to be easiest with express edition.
I've been using the free, single-user version of SourceGear Vault, which works fine as a local repository. Obviously you still need to run the stand-alone client since Express doesn't support add-ins, but it does the job.
Ideally the Express SKUs would support Codeplex natively!
Sign up for a personal Beanstalk account and use that. I've done it and never regretted it. Reliable SVN hosting for a cheap price.
But no, SVN and Tortoise make a pretty great solution for an individual developer.
VisualSVN server offers an easy way into SVN, and is free. Mix that with TortoiseSVN client and you're sorted.
Interestingly, TFS2010 may be interesting to single-devs/small-teams, but we'll see how it unfolds.