VS2010 compatibility

Jun 13, 2011 at 11:11 AM

Nick,

We first started looking at TFS Timesheets a while back, when we were investigating the benefits of TFS - but this process stalled a bit.

Now that we're revisiting the process, I just downloaded the latest version of TFS Timesheets and see that ther is now a reporting project in the solution.

Unfortunately, when loading the solution, the reporting project is not loaded because 'The project type is not supported by this installation'

We had a similar issue when we moved from VS2005 to VS2008, which meant that our SQL reporting service projects would no longer load, and we had to open the in the 'BID' application instead (Still not sure what microsoft were smoking when they decided to pull the rug on people like that)

Anyway, I suspect that there is some kind of add-in for VS2010, which we don't have, that is required in order to open the reporting project.

Do you have any suggestions on tis front?

Regards,

Bob

Jun 13, 2011 at 2:54 PM

OK - found a solution, so thought I'd post it up for others to benefit from.

The report project within the TFS Timesheet solution is for the creation of a Visual Studio extension, and this require the Visual Studio SDK.

This is available at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en

Then I encountered the next issue - a couple of assemblies could not be found...

Microsoft.TeamFoundation.WorkItemTracking.Controls
Microsoft.TeamFoundation.WorkItemTracking.Client

...it turns out that these are installed with the TFS server installation so, if you're developing on a machine that doesn't have the server software installed, you'll have to copy them from a machine that does - the locations of these files may be...

C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.WebAccess.Controls\10.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.WebAccess.Controls.dll
C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.WebAccess.WorkItemTracking\10.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.WebAccess.WorkItemTracking.dll

...but I can't rpomise that your installation will match mine.

I copied both of these DLLs to a 'Dependencies' folder within my project and updated the references to point to the file, to save any other developers from having to go through the same hassle.

Now then, I'm off to get a coffee and sit down to understand the code.

 

Coordinator
Jun 13, 2011 at 7:18 PM

Hi Bob,

Good to hear you managed to work your way through the configuration issues - documenting the 'getting started with the report control' is my last remaining action to formally move it out of beta, so I appologise that I haven't gotten that finished on time to save you some of the hassles you've encountered.

Regarding the dll's, yes they do need to be copied from the TFS server.  I've been trying to figure out the best way to do this in the codeplex source - as my normal rule is that a 'get latest' from source control should always build first time.  Problem in this instance however is that those particular assemblies are part of the TFS Server components themselves, so including them in the project itself would be a breach copyright.

Hopefully I can get some time over the next few weeks to tidy up the documentation and finally get the reports component to a 'release' state.

Code issues aside - have you had a chance to have a look at the binaries?  What are your thoughts on the reporting breakdown?

Regards,

Nick

Coordinator
Jun 13, 2011 at 8:01 PM

As a short term fix, I've added the items you've listed above to the "System Requirements for Development" section on the documentation page.

Regards,

Nick

Jun 14, 2011 at 11:38 AM

Hi Nick,

I agree with your comments about the DLLs - both from a 'check out and build' point of view, and a copyright point of view but, as we won't be distibuting the code externally, I don't have any qualms about checking them into our source control system.

As far as the reports are concerned, The Reporting panel is useful, but I suppect that our requirements will include the ability to do full blown report and charts based upon hours completed 'this week' etc, and this information isn't easily available (if at all) via the normal reporting channel.

Also, as far as the time tracking is concerned, We may end up modifying thing slightly, as I'm not sure the recent 'Prevent remaining hours from becoming negative' fix is ideal for us - as negative hours would show effort overrun. We're also undecided about the remining hours just being decremented by the amount of time added to the timesheet, as this doesn't allow for change to the 'Original estimate' (But then you could ague that this hsouldn't be changed after the workitem has been created)

Still feeling our way on TFS in general, so things are likely to change after we've had our next meeting on the subject.

Finally, I assume the the install app built by 'TimeSheetControl.Web.Setup.x64' project is used to install the timesheetcontrol onto the server, so that people accessing TFS via the web will be able to log hours - not ready to commit to installing this just yet, so thought I'd confirm this instead of installing in order to find out)

Thanks.

 

Bob

Coordinator
Jun 14, 2011 at 8:48 PM

Hi Bob,

The one piece of advice I'd like to offer if you are just looking at TFS (in general, not just the timesheet component) for the first time is resist the urge to start modifying all the processes and templates on day one.  There are a couple of reasons behind this comment, but basically it all boils down to reporting.  Often developers (who are better equipped to make changes to TFS) make a number of modifications to the workflow or fields on the work item forms.  This generally causes the reports to either break or stop working in an expected manner.  The true value of TFS is only realized if the data collected makes it all the way through the team and can be reported for project managers and stakeholders - so breaking these is to be avoided if possible.

An example of this is the way the Original, Remaining and Completed fields are used in the standard reports at the moment.  TFS Timesheets has been built around the standard usage of these fields, deliberately so that the standard reports can still be used as part of project lifecycle management.  For the standard reports to work correctly, concider having the Original Estimate based purely on what the project was baselined as when the estimates were produced.  The Remaining Time field should always be positive, and always have the most accurate estimate possible throughout the project - so if a developer realizes something is going to take an extra 8 hours (for some reason it is never less hours), then they would increase the Remaining Time accordingly.  The Completed time is obviously the actal time spent.

If these fields are used correctly, then project overrun can be shown both by the difference between the Original Estimate and the sum of Remaining and Completed estimates - and by the the standard project burn down report.  If the top line on the chart (which shows the sum of Remaining and Completed) increases this indicates overrun.  If this decreases then this indicates the project is tracking ahead of schedule.

To address some of your other questions and comments:

  • Understand the comment about needing a richer reporting system.  My goal so far has been to do everything in such a way that new components are not required to be installed (as opposed to configured) on the TFS Server by an administrator.  I have considered building a SSRS report for the output, but the reality is that this will likely require either some custom stored procedures, or a web service installation to provide the back-end.  The components as they are can be installed by a development team that chooses to use it, provided they can get an administrator to configure the work item definition.
  • Yes - the TimeSheetControl.Web.Setup installer is to be run on the box hosting your web access site - but be aware that this component is still a very early release.  While I consider the reporting component to be stable, it has not been released yet due to lack of documentation ... the web controls however still have a number of actual development tasks that need to be completed before I recommend using it in anger.
  • In terms of the "Not checking into source control" - I actually meant the codeplex source control, rather than a private company one - I thought that might get me in a bit of grief with Microsoft ...

Regards,

Nick

Jun 15, 2011 at 8:20 AM
Edited Jun 15, 2011 at 8:22 AM

Nick,

“The one piece of advice I'd like to offer if you are just looking at TFS (in general, not just the timesheet component) for the first time is resist the urge to start modifying all the processes and templates on day one. There are a couple of reasons behind this comment, but basically it all boils down to reporting. Often developers (who are better equipped to make changes to TFS) make a number of modifications to the workflow or fields on the work item forms. This generally causes the reports to either break or stop working in an expected manner. The true value of TFS is only realized if the data collected makes it all the way through the team and can be reported for project managers and stakeholders - so breaking these is to be avoided if possible.”

I totally agree, and this is something that we’ve been wary of since we started our investigations

“An example of this is the way the Original, Remaining and Completed fields are used in the standard reports at the moment. TFS Timesheets has been built around the standard usage of these fields, deliberately so that the standard reports can still be used as part of project lifecycle management. For the standard reports to work correctly, concider having the Original Estimate based purely on what the project was baselined as when the estimates were produced. The Remaining Time field should always be positive, and always have the most accurate estimate possible throughout the project - so if a developer realizes something is going to take an extra 8 hours (for some reason it is never less hours), then they would increase the Remaining Time accordingly. The Completed time is obviously the actal time spent.

If these fields are used correctly, then project overrun can be shown both by the difference between the Original Estimate and the sum of Remaining and Completed estimates - and by the the standard project burn down report. If the top line on the chart (which shows the sum of Remaining and Completed) increases this indicates overrun. If this decreases then this indicates the project is tracking ahead of schedule.”

This make perfect sense, so we’ll leave these fields alone

 

  • Understand the comment about needing a richer reporting system. My goal so far has been to do everything in such a way that new components are not required to be installed (as opposed to configured) on the TFS Server by an administrator. I have considered building a SSRS report for the output, but the reality is that this will likely require either some custom stored procedures, or a web service installation to provide the back-end. The components as they are can be installed by a development team that chooses to use it, provided they can get an administrator to configure the work item definition.

This may be a show-stopper for us, depending on what people are expecting to get out of the system.

  • Yes - the TimeSheetControl.Web.Setup installer is to be run on the box hosting your web access site - but be aware that this component is still a very early release. While I consider the reporting component to be stable, it has not been released yet due to lack of documentation ... the web controls however still have a number of actual development tasks that need to be completed before I recommend using it in anger.

Again, this might affect our ability to go forward with TFS timesheets, as our team members are quite often ‘in the field’, so web access may be their only option and not being able to log time could be problematic.

  • In terms of the "Not checking into source control" - I actually meant the codeplex source control, rather than a private company one - I thought that might get me in a bit of grief with Microsoft ...

Yes – I was definitely referring to the difference between your source control requirements/obligations and ours.

 

Keep up the good work.

Kind regards,

Bob