Does anyone know the best way to migrate all my groups screwturn wiki content(pages) over to Sharepoint's wiki? Currently I can use the Sharepoint Client API to pragmatically create a wiki page in sharepoint, so I can read in a screwturn page and save it as a Sharepoint page. This works, but I have to do the formatting (not done yet) and that seems like its going to be a real pain in the ass. Can anyone give some advice on either formatting or a better way to migrate, maybe with some tool or something?

If you keep each VS solution in one team project in TFS how do you handle situations where you have to work on two solutions with the same scrum iteration? Because you have different backlogs for each solution you would need to have two different sprints and that doesn't seem very efficient. right? You can't tie in work items from different team projects together and have them run under the same sprint/iteration. According to the TFS 2010 book by Wrox, one soltution they suggest is to put all applications into a single team project and seperate them by "areas" and "iteration". Isn't this a better solution then creating one team project for each and every solution given TFS limits team projects to something like 250 before performance degradation.

I'm a little confused about the TFS team project hierarchy. From what I have read just about everything for your group (projects/applications/etc) should be contained in one TFS team project? Can anyone concur with that statement? I, for some reason, thought that a single team project in TFS was mapped to one VS project/solution, but I think I misunderstood the hierarchy. I know it can but it seems like complications will arrise when you have to work on two team projects in the same scrum iteration. The work items don't translate over from one project to another.

OH! so you just keep one TFS project for all your applications? And separate them by folder in your TFS project. :) Does everyone agree with this?

Ok understood. Does anyone know, or can tell me how a project in TFS is structured? Do I create and put VS projects (dll, WPF, asp, etc) in a single TFS project and seperate them by folders? Or should I map a one-to-one with 1 Visual Studio project (ex. WPF) to one TFS project? In my TFS book it shows "product families" as a folder in a TFS project. I assume this means a VS project???

"Sharing a project is very dangerous and is rarely used. If you change an interface in project B, project A probably will no longer compile." you shouldn't be changing anything from interfaces (adding stuff is ok). Isn't that what the purpose of an interface is???

Let me ask you this question - My group has WPF application, we use three custom built libraries in this WPF application. These libraries are built as separate projects and have their own Subversion repositories. (4 Subversion repositories altogether) Question - Should we be using the .dll files in our WPF solution or should we be using the projects from Subversion? and bring the entire project into Visual Studio? Keep in mind our WPF application isn't the only application that uses these 3 libraries, we have other solutions that use these libraries. We are bringing in the library projects because we frequently modify these libraries when working on our WPF app. ***Here is my concern - we are now moving to TFS from Subversion and TFS has, whats called, TFS projects. Should we be creating 4 different TFS projects, one for each Subversion repository or should we be putting all projects into one TFS project? In TFS you have to create work items for each TFS project so if we have a user story that might need modification of both the WPF app and a library, if the library is its own TFS project, then we will have to create work items in 2 different TFS projects. And that seems redundant/annoying/not efficient.

Say I create a unit test that looks something like this below (autogenerated by VS) to test: [TestMethod()] public void UniContexPipeDataTest() { IResponse response = null; // TODO: Initialize to an appropriate value ISeries series = null; // TODO: Initialize to an appropriate value DateTime asof = new DateTime(); // TODO: Initialize to an appropriate value UniContext target = new UniContext(response, series, asof); target.PipeData(); Assert.Inconclusive("TODO: Implement code to verify target"); } I know I have to initialize response and series but they are big and have lots of other objects and Interfaces embedded within them that need to be instantiated for the UniContext contructor and PipeData() to work correctly. Q. How do I get the interfaces ready so that the constructor and method PipeData() pass in this unit test? Right now I can create these objects and interfaces to pass into the target but they will be empty. Both IResponse and ISeries have tons of embedded interfaces and other things like other objects and properties inside them that need to be created and instantiated with data. Do I need to start with the embedded object first and then do a ordered test unit test type deal? Do I need to learn about stubs, external dependencies and creating mocks objects? Any help/advice on this will be appreciated. --------------------------------------------------------------------------------

I have a method that creates a new process and calls the command line. I can get standardoutput into the procResults strings for most of my calls. But for some reason when I use this method to call devenv to build a c# solution I don't get anything in standardoutput. It seems like it finishes the call because all new files are built and I can see the last modified date is the current time, but the procResults string is empty. Here is my call: 'devenv alphacetui.sln /rebuild "debug|x86"' it seems like it finishes ok because I get a p.Exitcode = 0; Does anyone have experience calling devenv from system.process or know why I'm not getting output? when I run devenv alphacetui.sln /rebuild "debug|x86" from the command line it works fine and I can see the output in the command window. public void method() { Process p = new Process(); p.StartInfo.FileName = "devenv"; p.StartInfo.Arguments = "alphacetui.sln /rebuild \"debug|x86\""; p.StartInfo.UseShellExecute = false; p.StartInfo.RedirectStandardOutput = true; p.Start(); string procResults = p.StandardOutput.ReadToEnd(); p.WaitForExit(); }