|
Deus Rex posted:Let's be clear about what you're saying here - TFS is free up to 5 developers until you have to purchase a support contract from some TFS consultant to figure out how to make it work. TFS once it's set up is really straightforward. What you need to make sure is that you're 100% confident with how you want to work with it prior to setup. We changed work item templates recently, and that was a BITCH and meant we had to create a new project collection and lose all of our source control history. Why, why, why is source control so indelibly matted into work item tracking. I understand losing all of the work items (which have been easily exported and remapped via Excel) but we had to super tediously recreate all our branches and do a fuckton of baseless merges to get us back working again. Also, branches. Creating feature branches in TFS is a real tedious experience, I wish it did them properly like Git. In short, don't get a support contract, hire a guy who knows what the gently caress he's doing for a couple of days before you set yourself up in an environment you will not *ever* be able to change unless you want to scrap the whole thing and start again.
|
# ¿ Jun 26, 2014 12:14 |
|
|
# ¿ May 3, 2024 00:22 |
|
uXs posted:Anyone have any experience connecting to Sharepoint services? Can't say specifically about Sharepoint, but this stopped us dead trying to intiialise an old web service on a new machine yesterday: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/6550f476-9c8c-4056-a153-2074fa2f6993/error-cs2001-cs2008 The response we were getting was "cannot resolve <servername>" as well. Fix was to give permission for the asp.net process to modify the Windows/Temp directory. E: wrong url
|
# ¿ Jul 16, 2014 14:24 |
|
Newf posted:What method does HashSet<> use in order to determine whether an element is already a member of the set?
|
# ¿ Jul 16, 2014 14:46 |
|
uXs posted:That... looks like a completely different problem? The problem happened to us (and again, may be completely different to your problem, I'm not sitting at your desk) that the call to the web service was not reporting the actual error, but instead simply failing at the attempt to connect to the web service in teh production environment. Only sticking in shitloads of trace code to try and find out what the problem was revealed the error. The symptom was the same, that I could access a web service from a browser, from SoapUI, from anywhere but the app installed in an IIS environment. You said you can connect if using different credentials, so your problem does suggest it's a permissions issue? E: sorry misread the bit about it working from a browser then working from your application. Maybe your browser is accessing via different credentials, and therefore creating whatever files the web service connection needs to be in the temp directory? Betjeman fucked around with this message at 16:03 on Jul 16, 2014 |
# ¿ Jul 16, 2014 15:59 |