I need to write a proof of concept with the TFS API (fetching data from tfs server regarding workitems and put this data in our tables).
Can Any body suggest a way to do this without setting up my own TFS Server.
You can just set up one on the MS Cloud TFS which is now on tfs.visualstudio.com (previously called TFSPreview.com.
With TFS, your code is accessible from anywhere. You can check in code
directly from Visual Studio and Eclipse, or you can use command-line
tools to check in your code from Xcode and other IDEs. Since it's all
in the cloud, your team can get started quickly with no infrastructure
to manage.
Related
I'll preface this with the fact that I'm very new to Visual Studio, so I am prepared to hear that my problem lies in something I haven't read yet.
I have a database first project in Visual Studio 2015 v.3 that I am attempting to publish to an existing Azure account and resource group.
I have successfully converted it to an Azure project via the menu options: Build > Publish to Microsoft Azure.
I can successfully build both the local and the Azure projects without error, but whenever I attempt to edit the Roles in the Azure project to add the Azure connection string as per the tutorial found here, the program hangs up irretrievably. This makes my twelfth attempt to edit the Roles.
It took Visual Studio five tries to publish to Microsoft Azure using the menu options above.
To fix this, I have tried all of the following:
Restarting my computer
Restarting my Azure connection
Restarting Visual Studio
Confirming Visual Studio's connection to the Azure account I want to publish to
Checking to be sure my Azure SDK (version 2.9.1) and Visual Studio (version 3) installations are the most recent versions and that the installation appears to be clean
Removing the Azure portion of the project, cleaning and rebuilding the local solution, and reattempting to publish to Azure
Cleaning and building both solutions before attempting to edit the Roles for the Azure portion of the solution
Confirming that the resource group I am attempting to publish to does exist at the specified connection string and contains the necessary resources (in this case, a server and an SQL database)
I am attempting to connect (for now) with HTTP and not HTTPS, as per other similar questions about Visual Studio 2015 freezing while publishing to Azure
Confirming that I am able to connect remotely to Azure via Visual Studio (this is probably a gimmie, but it doesn't hurt to be specific)
I also notice that when I attempt to browse the Azure features on the menu to the left of the Visual Studio window, Visual Studio freezes (particularly if I click on the links for Data Factory, Mobile Services, Service Bus, and Virtual Machine).
Server Explorer is showing that I am logged in to Azure with the account I'm attempting to publish to.
I can reach, read, and edit the local database files. I can also run the local project without error.
The application was configured to use an IIS Web Server and uses SQL Express. It froze repeatedly while attempting to change configurations from the IIS Express and LocalDB default to IIS Web and SQL Express.
I do have the application backed up locally as well as via a private GitHub repo just in case I manage to bork it permanently trying to do this.
I would very much appreciate the help.
edited to add: I'm currently running Windows 10.
edited again to add: The task manager shows the load to memory and CPU during the period when Visual Studio is frozen to be less than 15%, the majority of which is not Visual Studio. It shouldn't be a hardware issue, but I did try closing the majority of the background services that were non-essential just in case there was some sort of conflict occurring.
Making this an answer instead of a comment because while it may be a silly oversight, there's bound to be someone who would benefit from the answer.
The problem was that I was working from a local copy of a remote database. When it came time to push up to the remote, I deleted the local copy and data interface model, and reconstituted the model on the remote database, creating several connection strings in Web.config.
When I attempted from there to publish, Visual Studio read the connection strings in the Web.config for the project and attempted to hunt down the local and over-write the remote database.
Removing all other connection strings from the Web.config for the project removed many of the problems with freezing and hanging that I was experiencing (and made the project run faster by resolving the search for associated project resources.)
Lesson learned: make sure you clean your Web.config file before attempting to push to remote.
I am currently building a C# Web API and publishing it to Azure. I'm using Visual Studio Online to host my TFS source control. Of course, Azure has options to use their build servers, but those are not free after your first 60 minutes of build time, and this is an educational endeavor.
Is it possible to set up a VM (or use my local machine) as the TFS build server for continuous integration? How would I go about that? My initial guess is that this is possible, and I just am not googling using the correct terminology to find what I'm looking for.
I'm not terribly savvy on TFS in depth, so please feel free to correct any incorrect assumptions I have.
You can create a Windows Server VM in Azure, and simply install TFS 2013 and when you get to the configuration wizard just choose to configure Build Server only. When it asks you for the URL to your collection, give it the URL for your VSO collection (e.g. https://foo.visualstudio.com/DefaultCollection)
Pretty straightforward to do, I've done it many times.
PS - Of course you could use an on-premise VM also, but I like the option of using a VM in Azure.
You can download and install TFS on your local server/machine: VS & TFS Download page
But if you need only build server you can use any other CI server as well (e.g. TeamCity or Jenkins) and build your code from visualstudio.com there.
My team works on SQL database and asp.net in MS Visual Studio 2008. We have own server where our current repository is stored. We use Visual SourceSafe (VSS) 6.0 as the source control. Recently we decided the switch to the latest source control technologies such as Team Foundation Server or GIT.
I was able to create the GIT repository in our server and all team members were able to commit changes in the repository through Visual Studio 2013. But we like the nice GUI of Team foundation server and all of it features like source control explorer, check-out files for edit, managing users group and permission through TFS control panel, etc. It would be convenient for us if we have access to those features.
My question is can we use Visual Studio Team Services by maintaining our central repository in our own server? Or we have to host our source code in Visual Studio Team Services or any other third party repository? We do not want to store our code to any other places other than our own server and still want to use the TFS features.
Thank you for your help in advance.
YES, TFS allows you to store your repository on your own private server. Just install TFS on the server, then Visual Studio will connect to it for each client machine and you can use source control etc.
Due to some (insane) limitation at my customer, I built up a WCF layer using Azure, just as a proof of concept. Now, what is a smooth way to re-deploy it to their on-premises server? Is there such a way?
I understand that the publishing of my service to the cloud is a nice luxury that can't be performed as easily when deploying on-premises. :(
Because of some (equivalently insane) limitations, I'm not able to connect my computer (with the IDE and source code) to the internal net of the customer. I might be able to get an IDE installed on their computer, though. Is moving the source code files and recompiling the only option?
In a perfect world, I'd like to copy the entire project to the customer's computer and just change some settings in a deployment file (or whatever thing stores that information). Is it possible?
Well, what about the deploying the solution to the local temp folder by using the Deploy Wizard from Visual Studio and then simply create by hands a new application on server side and copy all files there.
I am developing a C#, MVC4, EF5 Code First application on .NET in Visual Studio 2012 and have used the VS publish mechanism to deploy it to an Azure Website with an Azure SQL Database.
I now want to use Git and GitHub for version control and involve others in the project.
However, although I am familiar with using Git in a LAMP environment, I have no experience of using Git with Windows, Azure Websites and a compiled environment.
I would like to use the Azure Website as the production server, another Azure Website as a Staging server, developer Windows machines using Visual Studio for development and GitHub as the central repository.
There is a helpful article here: http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-git/ . I can get my head around what would be needed here for, say, a PHP application on Azure. But I am unsure of the best approach with a compiled application and what I can achieve using Azure Websites and Visual Studio.
A nudge or two in the right direction would be greatly appreciated!
don't publish from VS to azure, instead setup your azure website to pull from the github repo. the deployment process compiles your solution.
watch http://www.youtube.com/watch?v=5NGieL0tinw&feature=youtu.be&hd=1 or read http://vishaljoshi.blogspot.com/2012/09/continuous-deployment-from-github-to.html
Also SocttGu announced this on his blog # http://weblogs.asp.net/scottgu/archive/2012/09/17/announcing-great-improvements-to-windows-azure-web-sites.aspx he also talks about a cool feature of publishing branches, this will nail your requirement for a stage server and production server. Have a stage branch and a production branch and merge to them as desired. see the section "Support for multiple branches"
looks like they added support for private repos finally.
appharbor is a competitor to azure that does something similar.
You are basically introducing a new step with the requirement that the source code must be compiled before it can be deployed to the server. Where you implement this step is up to you. You could:
Ensure that your target server has the capabilities to compile the source code (some Continuous Integration tools could help with this, such as CruiseControl.NET). This has the caveat that the target server be able to compile source code (possibly even requiring Visual Studio to be installed), so that may not be an option.
Check the compiled binaries into source control. You could keep these compiled binaries separate from the main source branch, to keep things clean. Deploy the binaries to the target server.
Some hybrid of the previous two options is also possible; you could set up a Continuous Integration server with CruiseControl.NET, which can check out the current source, build it, and check the resulting binary back into a special branch, then deploy that branch to your target Server.