This project has moved and is read-only. For the latest updates, please go here.


The custom tool 'CsdFileGenerator' failed. Unable to retrieve Visual Studio ProjectItem. Try running the tool again.


I was using a previous version of Csd in a project and I upgraded to the latest version this afternoon. After installing the new version, I had to recreate the config sections using v1.6.1, but it fails to generate a schema, sample code or source code. Visual Studio displays a warning:
The custom tool 'CsdFileGenerator' failed. Unable to retrieve Visual Studio ProjectItem. Try running the tool again.
The project this is being used in is a standard class library and I used the project item to create the config sections file. I created a new solution and tried your custom project template and it works. I tried creating a new Csd project in my existing solution and it fails.
I'm using Visual Studio 2008 Team Suite, with VS 2008 SDK 1.1 installed.

file attachments

Closed Jun 30, 2011 at 4:17 PM by andym1978
I merged my fixes from the VS2010 version to the 1.6.1 version. It appears to have resolved the issue.


alexschrod wrote Jan 21, 2010 at 4:56 PM

Would you be able to zip up your solution and attach it to this issue? That would be very helpful in my pursuit of the problem.

BonafideSoftware wrote Jan 22, 2010 at 6:07 AM

Hi Alex,

This is a commercial project, so I've been relunctant to send you my solution. Instead, I did some investigating/testing in a seperate solution. I was able to reproduce my error as well as finding a bunch of 'new' issues. Here's the summary:

• Class Library project
o In a default configuration, is not compatible with Csd
o After manually adding service to end of file, is compatible.
• Csd Project Template
o Works at solution root
o Fails in a solution folder
• Csd Project Item
o Works when the project is not in a solution folder and after service entry has been added.
o Fails when the project is moved to a solution folder
 Works when it’s moved back.
o Fails when created in a project folder
o Works if created in at project root and then moved to a project folder.

I tried about 17 scenarios, with 12 scenarios failing, 5 working and 1 workaround. They're all listed in the document 'Debugging Csd.docx' and the test solution is attached.

wrote Jan 22, 2010 at 6:07 AM

alexschrod wrote Jan 22, 2010 at 1:11 PM

Wow, that's quite a comprehensive testing you've done there. I appreciate that very much.

I'll get to fixing these things the next time I work on CSD. As a temporary workaround, all I can really suggest is that you use one of the configurations you found that work when using CSD... I guess. :-)

wrote Jan 25, 2010 at 9:25 AM

wrote Feb 20, 2010 at 4:12 PM

wrote Feb 20, 2010 at 6:21 PM

BVeldhoen wrote Feb 28, 2010 at 1:50 PM

I can confirm this issue when the configuration project is within a solution folder. My first guess would be that the templates assume that the project is in one directory deeper than the solution file. So something like would work:

  • <solutionname>.sln
  • configurationprojectname
    • <configurationprojectname>.csproj
I can add as a workaround creating a solution, which you use only and especially for editing the configuration project. So you can create one solution that only contains your configuration project. As long as you make sure that this solution is one level up from the configuration project (like shown above).

wrote Mar 11, 2010 at 10:12 AM

wrote Mar 29, 2010 at 9:59 AM

wrote Apr 20, 2010 at 4:00 PM

TheMrkeys wrote Jun 5, 2010 at 12:09 AM

Could you create a seperate solution that generates the problem that I can add as a regression test?

wrote Jun 25, 2010 at 9:45 AM

wrote Dec 1, 2010 at 1:48 PM

andym1978 wrote Mar 31, 2011 at 8:48 PM

I figured out what is causing the failures when "solution folders" exist and create an ugly and "hacky" solution. What's happening, is solution folders are being returned as project items, but they are actually containers for the project items we are looking for. In my "hack", I simply do a check for a SubProject on the ProjectItem and use the SubProject instead (if found). I didn't bother to clean up my ugly code since it already solved my problems, but I'm sure someone else might want to build upon it. Modify the "VsMultipleFileGenerator.cs" file like below at the "Generate" method:

public int Generate(string wszInputFilePath, string bstrInputFileContents, string wszDefaultNamespace, IntPtr[] rgbOutputFileContents, out uint pcbOutput,
        Microsoft.VisualStudio.Shell.Interop.IVsGeneratorProgress pGenerateProgress)
        this.bstrInputFileContents = bstrInputFileContents;
        this.wszInputFilePath = wszInputFilePath;
        this._generatorProgress = pGenerateProgress;

        // Look through all the projects in the solution
        DTE dte = (DTE)Package.GetGlobalService(typeof(DTE));
        ProjectItem item = null;

        foreach( Project __project in dte.Solution.Projects )
                int iFound = 0;
                uint itemId = 0;

                // ABM FIX: Fixes bug where solution folders caused tool to fail.
                // TODO: Clean up code, especially in case multiple project items exist.
                // TODO: Fix annoyance where generated file name has "1" appended.
                Project project = __project;
                if (__project.ProjectItems.Count > 0)
                    foreach (ProjectItem projectItem in __project.ProjectItems)
                        if (projectItem.SubProject != null)
                            project = projectItem.SubProject;

                if( string.IsNullOrEmpty( project.FileName ) || !File.Exists( project.FileName ) )
.... .. . .. . . . . . . ALL CODE BELOW HERE IS UNCHANGED

alexschrod wrote Apr 1, 2011 at 5:26 AM

Thanks, andym1978, for your input, but I've already re-written most of that code you were looking at there. I haven't checked it in yet, because I haven't been able to test it all thoroughly yet, but I believe my new way of pulling out the Project is much cleaner and less prone to weird errors like this than before.

andym1978 wrote Apr 11, 2011 at 2:25 PM


Thats great to hear! Even with the bugs, I love this project. The ONLY problem I am still having is the "Value does not fall within expected range" error when right clicking the designer window in VS2010. If you have a solution to this issue, even an ugly one, I would be extremely grateful if you could point me in the right direction on a resolution. Currently, this issue has made the designer unusable for me in VS2010 (I cannot add attributes). Thank you for the work on this project.

andym1978 wrote Apr 11, 2011 at 3:09 PM

I found the workaround for adding attributes in another post. This will work fine for now until a fix is found.


LEFT click the Attributes section of the configuration item to add attributes to
press INSERT on keyboard and enter a valid name
choose Type in properties window

andym1978 wrote Jun 23, 2011 at 10:50 PM

I have fixed this issue on the Visual Studio 2010 version (2.0). It has not yet been integrated into the 1.x builds.

wrote Jun 30, 2011 at 4:17 PM

wrote Feb 22, 2013 at 12:30 AM

wrote May 16, 2013 at 12:04 PM