I am having a problem where My Eclipse 9.1 is not able to connect to multiple projects in 2010 using the Team Explorer Everywhere plugin. If I try to connect a second project, it disconnects me from the first one. I can not find any way to be able to pull down multiple projects like I was in TFS 2008.
Any Ideas?
This is as-designed. Team Explorer Everywhere can only connect to a single Team Project Collection at a time. There are myriad reasons why this is the case, but all are to preserve the notion of atomic operations against the server. Some operations (for example, check-in) simply must be scoped to a single server instance in order to make sense.
Since a single changeset is atomic in TFS, an attempt to check-in multiple pending changes either all succeed or all fail. Consider if you had pending changes from two different servers: you cannot commit all these changes as a single changeset - one server could reject your check-in due to conflicts, while the other could proceed successfully. This is, at best, confusing, but most likely actually leaves your projects in an inconsistent state since there may be dependencies between these projects. Since there are distinct changesets for each server, the UI must reflect that.
After much deliberation and experimentation, we concluded that the best user experience is simply to have an experience where you can import projects from multiple TFS servers, but you must select which server you want to work with in the UI by selecting which one is currently "online". All TFS functionality is available for the online server which a limited subset of the TFS functionality is available to the other projects.
We would recommend that you consolidate your Java projects to a single Team Project Collection if you need to import all of them.
This behavior is unchanged from any previous versions of the software, including before the acquisition of the technology by Microsoft (when the product was still part of Teamprise Client Suite.)
Also note that the scope of commands available to "offline" projects has increased dramatically in TFS 2012 thanks to the new Local Workspace functionality.
Related
We are maintaining code for one of our clients.
Initially, we copied all the source code that they have and added it to our TFS 2012.
We modify the code any time they need a bug fix and give the client deployment packages.
Now, client wants all the latest code in their TFS 2012 as well.
Is there a way to update their source code with our changes? ...
preferably automatically (i.e. power shell script) and preferably with history of changes.
There are many approaches each with some pros and cons. The following are the main options I would suggest.
Database backup and restore
This is the only path that guarantees full fidelity. It has some technical difficulties (e.g. SQL Server version and editions) and political (how much information you care to expose, how much effort you want to put in sanitizing your data).
Project synchronization
There are some tools, most notably the Integration Platform, that use the API to read and reply the changes from one system to the other. It requires that the syncing tool can see both systems via HTTP(S).
It gives you the flexibility to project only some data (say source code not work items).
Keep in mind that you will always loose something in the process: the Changeset number will never match, some users details.
Dumb dump
Give up conserving full history and be content to share the code.
This is the simplest to implement: get all the code, ship and check into the other system. You can associate release notes in the check-in.
Two simple scripts using TF.exe is all you need.
You can use TFS Integration Tool to achieve the code migration(TFS-to-TFS). TFS Integration Tool moving data between two different servers. The migration is done through the APIs of TFS, and there also some limitations.(Check the above link for more info)
Detail steps please see my answer in this question: Move Team Project to another Project Collection TFS 2013
We use TFS2012 and VS2012 (some people use Update1 and some Update2). ). In some people's machines, we get:
TF400324: Team Foundation services are not available from server vstfps\Protection.
Technical information (for administrator):
Page not found.
This happens on any source control access, both in VS2012 and when running "tf.exe get". However, other TFS services work fine, for example work item queries.
I've uninstalled and re-installed VS (this time without Update2), and the problem persists.
I found a similar problem report, though it's somewhat different, and either way has no fix.
Debugging with Netmon, I noticed that affected machines use a different URI:
Good: /tfs/Protection/VersionControl/v4.0/repository.asmx
Bad: /tfs/Protection/VersionControl/v5.0/repository.asmx
What determines the URI the machine uses?
How can I change that?
Workaround: Close Visual Studio and related apps, then delete %LocalAppData%\Microsoft\Team Foundation\4.0\Cache.
Reason: (reconstructed from reports from my sysadmin...)
My TFS2012 RTM server was cloned from an existing server, keeping the same collection GUID. Effects:
The old server had Update1 installed and uninstalled. TFS2012 RTM only supported v4.0 URI, while TFS2012 Update1 added v5.0. So sometimes, clients would get confused and go to the old server, get the v5.0 URI, and keep that cached in ...\Cache\<guid>\LocationServiceData.config.
We've had TFS builds fail with "Can't copy activity logs", since they tried to copy to the old server.
Fix: Change the collection GUID at the new server, by running:
tfsconfig ChangeServerID /sqlinstance:<SQLInstanceName> /databasename:tfs_configuration
afterwards, people need to clean the cache one last time and that's it.
So, I'm about to embark on a fairly lengthy, time consuming project that could net me some good results/rewards - and I'd like to give everything the attention and focus it deserves. I will be the sole developer, and I'm experienced in that capacity (about 13 years in the industry). I've just never had to be responsible for EVERY choice so I'd like to throw this out there for some feedback. This is going to be a website.
Dev Tools on Win x64 workstation:
VS2010
SourceGear Client
FileZilla
UltraEdit
SQL 2008 Mgmt Studio
I will have my own DB Server machine also, which will run SQL 2008 for both the web DB and will host the Soucegear repository DB.
I'd like to have an automated build process that includes
pulling the latest code from the repository
checking it against rules (ala FX Cop)
compile the code
running a series of tests against the new compilation (unit tests?)
Any suggestion on tools to do these tasks? Should I just write & execute scripts to do certain steps?
Backups! - I'd like the source code repository and web files, graphics, media, etc. for the site backed up regularly. I use Mozy for my own personal backups - is there something more suitable for this kind of backup? Windows Home Server or something like that perhaps?
Lastly - what am I not thinking of that needs to be on my radar? For example, I plan on using jQuery but only have limited experience with it - any good javascript tools besides VS2010? How to most web devs test their sites across the plethora of browsers available? Should I use minify-ing tools for the web content - which are best? I've built plenty of web sites & applications before - this is just my first real "commercial" venture and I'd like it be founded in solid practices.
I, too, am a single developer and use much the same tools as you...
Couple of things...OK...it grew to more than a couple...
I like to use UltraEdit sometimes for editing my javascript files...as it has some features that VS2008 lacks...not sure abt VS2010...mainly a function list to aid in navigation of the file.
I also use JavaScript Lint to check the syntax of my javascript files...you can integrate it into UltraEdit...my choice...or VS...or both.
I use subversion for source code control...Visual SVN for the server and Tortoise for the client...both free
For backup I recently started using DropBox...you can point DropBox to the folder that holds your files and it will sync whenever DropBox starts (and it will keep the files synched on multiple machines...so if you have an offsite machine...you're covered if something happens at your main development site).
If you'll be using LINQ at all...I'd recommend getting a copy of LinqPad It's free, but you can pay to get "intellisense"...the examples included are fantastic learning tools.
When using jQuery...look for plug-ins that do what you're looking for...
I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Continuous builds
Daily Builds on a development server
When we release something to test we merge the code to the Main bransch in the version management system (TFS)
When tested and ready for production then we merge the main bransch to the release bransch
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly until you try to collaborate 'One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.