Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

  • Brian Smith's Microsoft Project Support Blog

    COMException on x64 platforms when automating the Project client via the Primary Interop Assembly (PIA)


    ***UPDATE*** Hotfix now available -  

    You may see this error when using the CodePlex Test Data Population sample for creating project data using the WinProj tab, or just using your own code to automate winproj.exe (the Microsoft Office Project Professional 2007 client application).  It is only a problem with the object model interaction and not an issue with PSI calls.  It is the Tasks.Add() method which is the trigger for the problem, and it will work just fine on x86, but fails on x64.

    Currently the x64 platforms do not support more than 1024 methods on an object (which comes down to around 1017 once the COM standard methods are deducted) and the Tasks object has a lot of methods.

    The error is:

    Error HRESULT E_FAIL has been returned from a call to a COM component. System.Collections.ListDictionaryInternal.

    One work around we have found is re-writing to avoid using the Tasks method.  So the following code:

    protected void Page_Load(object sender, EventArgs e)
    string filename = "c:\\test.mpp";
    ApplicationClass a = new ApplicationClass();
    a.FileNew(Type.Missing, Type.Missing, Type.Missing, Type.Missing);
    Microsoft.Office.Interop.MSProject.Project p = a.ActiveProject;
     p.Tasks.Add("test", Type.Missing);
    p.SaveAs(filename, PjFileFormat.pjMPP, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, "MSProject.mpp.9", Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
    lblfilename.Text = filename;

    could be re-written as:

    protected void Page_Load(object sender, EventArgs e)
    MSProject.Application objAppProject;
    MSProject.Project objProject;
    string filename = "c:\\test.mpp";
    objAppProject = new Microsoft.Office.Interop.MSProject.Application();
    objAppProject.FileNew(Type.Missing, Type.Missing, Type.Missing, Type.Missing);
    objAppProject.EditGoTo(1, Type.Missing);
    objAppProject.SetTaskField("Name", "Test", true, Type.Missing, 1, Type.Missing);
    objProject = objAppProject.ActiveProject;
    objProject.SaveAs(filename, MSProject.PjFileFormat.pjMPP, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, "MSProject.mpp.9", Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
    lblfilename.Text = filename;

    and would work in both x86 and x64 environments.

    This is currently being worked on by the Windows teams and we are anticipating a fix.

  • Brian Smith's Microsoft Project Support Blog

    Loading projects from server or mpp files can be slow with some security products


    One thing we have seen recently in support is several cases where security products can slow down the loading of projects into Project Professional 2007 both from mpp files or from Project Server 2007 connections.  An example of this is McAfee Host Intrusion Prevention, and we have seen this make projects load up to ten times slower.  We are working with McAfee to see if there is a workaround for this and I would certainly not suggest disabling any security products on your servers.  It might however be worth testing in a secure environment if you think your speed might be affected by something like this - if only to eliminate it as a "suspect".

    I'm hoping we may just need to exclude something and things will speed up - if anyone has experience of HIP and can give me pointers I'm happy to talk.

  • Brian Smith's Microsoft Project Support Blog

    Timesheet Classifications - what they don't do


    With the change in relationship between time tracking in timesheets, and the updating of status in tasks, that we introduced in Project Server 2007 there has been some confusion.  One area that after working on a case yesterday needs a little more explanation is timesheet classifications.  Where you create these in PWA it give the following description:

    Edit, Enter Line Classification

    You can duplicate timesheet lines for business purposes or accounting reasons. To do this, define timesheet line Classifications, which will become the unique identifier for a timesheet line.

    What it doesn't say directly is that these classifications are not for tasks - and only the timesheet classification of "Standard" can be imported to the "My Tasks" page through "Import Timesheets".  All other classification types will be ignored and any lines will not display in the grid to be imported.

    The intention behind this design is that other classifications can be used for business analysis of time related to the task that was not productive as far as working the task.  So you may have spent 2 hours traveling to perform a task - and you may bill the customer, but this wasn't something directly related to performing the task - and in this scenario was not included in the planned time to perform the task.  Obviously there could be other ways to handle this and the travel may well be a task on its own. 

    In the support incident where this caused some issues the customer was trying to use the classifications as a way of flagging different activities within the same task - but as the only the standard line goes through to the time tracking in the project this would not work.  The solution agreed here is that the project requires tasks for all the different activities being performed.  You could also do some sort of server side event that allows you to add time in different timesheet classifications against the same task - and then these get consolidated in the "Standard" row - but analysis would only be available in the timesheet and reporting database.


    As an example only the 6h highlighted for the ABC Outlook Task 1 would be available for import to "My Tasks" - the research and travel time would not. 

    I hope this helps clear up any misunderstanding of this feature.

  • Brian Smith's Microsoft Project Support Blog

    Is your Project Server 2007 queue running a few minutes slow?


    Not sure if you remember the problem we had with Daylight Savings Time last year - but basically when adding jobs to the queue they have a time when they should be processed - and most times this time is "now" or the current time.  Well with the DST problem "now" was actually set in one hour's time - so some jobs just sat there for a while.

    We have seen a couple of recent cases where time differences between servers can give this same problem.  A server puts a job on the queue and the timestamp for "now" gets set a couple of minutes in the future - because the SQL Server machine doesn't have the same time as the Project Server machine.  When the queue gets to this job it will just let it sleep until the right time arrives.  This can look like a slow queue, when in fact it is doing what it is told.  Keeping your servers clocks in sync will avoid this problem.  The ULS logs will show this as jobs sleeping when there does appear to be any reason.  In most "sleeping" cases the reason appears in the log - such as a missing custom field in the reporting DB will put a project reporting publish to sleep.

    Technorati Tags: Project Server 2007

  • Brian Smith's Microsoft Project Support Blog

    Join the Project Server Developer Community


    Apologies if you have already read this on the Programmability blog - but an excellent chance to share your development experiences with others - and hopefully learn some stuff too!

    Leveraging the development aspects of Project Server 2007 spans a wide range of skills.  PWA customizations (ASP.NET), workflow development, line of business applications integration using the PSI, extending Project Server functionality using server side events, specialized reporting from the Project Server databases and experience using VSTO are all areas of discussion. 

    The Project Server Product Group currently supports these efforts through channels such as the this Blog, the Programmability Weblog, Project.Server Discussion, Project.Developer Discussion, and the Project 2007 Team Blog.

    To streamline and augment the existing efforts, we are seeking developers to join the already established Project.Developer Discussion Group

    By joining we invite you to share and discover knowledge about Project Server 2007's highly extensible out-of-the-box developer's platform, access Project Server Developer best practices, utilize a technical window back to the MS Project Server Development Group, and take part in several specialized webcasts on Development topics coming up in the next couple months.

    To identify yourself as someone that would like to join the Development Community, please contact Joyce Bileau, v-joyceb@microsoft for more information.

    To join, go to

Page 77 of 94 (468 items) «7576777879»