Property Accessor 'Versions' ... Exception 'Value cannot be null. Parameter name: name'

Topics: General Discussion, General Questions, Sandcastle
Nov 25, 2007 at 5:47 AM
I just installed the latest version of DocProject, and I have been unable to build the project or edit the main project properties (API topic management, API topic designer). The docproj project property Version management is throwing an exception that seems to be preventing builds or configuration. The full exception message is:

Property accessor 'Versions' on object 'DaveSexton.DocProject.Sandcastle.SandcastleProjectOptions' throw the following exception: 'Value cannot be null. Parameter name: name'.

I have been unable to find out where these docproj settings are stored, so I have been unable to try and set the value that seems to be missing. Is there an underlying .xml file or something somewhere that stores each DocProject's settings and configuration? If its purposely hidden, I would request that it be unhidden, and made available to developers, preferably in a human-readable and human editable format like xml.

Coordinator
Nov 25, 2007 at 8:11 AM
Hi,

The name parameter to which the error is referring is probably the name of a Sandcastle presentation style, which indicates that either Sandcastle is not installed, out-dated or the %DXROOT% environment variable is invalid. You can check Application event log for a stack trace that confirms this. See How to Diagnose And Resolve Issues for help finding the event log.

I'm going to make a work item for adding a more descriptive error message.

As for the cause, did you close VS before installing the Sandcastle Oct. 2007 CTP? Regardless, try rebooting. I bet it's just that Sandcastle's %DXROOT% environment variable is not being read properly by DocProject.

Most configuration is stored in the MSBuild project file itself. Some configuration is stored in XML files found in the Help\Settings folder, although some of the files do not appear unless you use their associated feature, such as version management or dynamic filters. There are also some settings files (XML) saved in Isolated Storage. However, these settings apply to build engine providers and GUI controls, and so are not customizable on a per-project basis.

- Dave
Nov 25, 2007 at 5:07 PM
Hi Dave, and thanks for another reply. :-) I did close all my VS instances, and I've also rebooted. The DXROOT environment variable does exist, but, there are two of them. One is a user variable that points to the Sandcastle version that comes with the VS2005 SDK, and the other is a system variable that was added when I installed the October CTP. I'm not sure which one DocProject is using, but I may get rid of the user one in favor of the system one, and see how things go.
Nov 25, 2007 at 5:20 PM
Removing the user version of DXROOT did not have any effect. I also can't seem to find any msbuild project files anywhere for any DocProject I create. I think this bug is preventing a project file from actually being created, or something. I've deleted the project, created it again, and created other DocProjects for different assemblies, but they all have the same problem. I'm running Vista Ultimate with all the latest updates, and Visual Studio 2005 Pro.
Coordinator
Nov 25, 2007 at 6:02 PM
Hi,

The latest version of Sandcastle installs DXROOT as a system variable, but previous versions did not. Also, the VS 2005 SDK installs DXROOT as a user variable and it replaces the existing path. It's an older version of Sandcastle though (March CTP, IIRC). This is a common source of problems (it's documented on Sandcastle's download page and in DocProject's release notes). DocProject uses the latest version, probably installed at C:\Program Files\Sandcastle, so keeping the variable with system scope was correct :)


Removing the user version of DXROOT did not have any effect.

Surprising.


I also can't seem to find any msbuild project files anywhere for any DocProject I create. I think this bug is preventing a project file from actually being created, or something.

The MSBuild project file is the DocProject or DocSite project file itself; e.g., test1.csproj, test2.vbproj. So if you were able to create a new project and at least view its options in the DocProject Properties window, regardless of whether there are errors displayed, then you must have a project file already :)


I've deleted the project, created it again, and created other DocProjects for different assemblies, but they all have the same problem. I'm running Vista Ultimate with all the latest updates, and Visual Studio 2005 Pro.

This is a strange one. That stack trace would really be helpful to me :)

Please check the Application event log for detailed error messages and stack traces (DocProject is the event source) and post them here or send them to me through my contact form. See How to Diagnose And Resolve Issues for help finding the appropriate event log.
Nov 25, 2007 at 7:58 PM
Edited Nov 25, 2007 at 8:03 PM
Regarding the msbuild project...I thought you were creating your own .build file or something...I'm a big fan of seggregation. :P So, if I open the .csproj file in notepad, I see the standard C# project settings that every project has. I found one new thing, with the following markup:

<ProjectExtensions>
<VisualStudio>
<UserProperties BuildEngineProviderName="Sandcastle" IsDocProject="true" ProcessComponentTypeName="Pride.Data.Doc.BuildProcess" />
</VisualStudio>
</ProjectExtensions>

Beyond that, I couldn't find any of the settings that appear when I right-click the project node in VS2005, and choose to edit hte DocProject properties (vs. the project properties, which opens up the standard C# project settings document). I have been digging around for a while trying to find where the configuration for the property "Version Management: Specify multiple versions for each project reference and external source." is stored. Its still causing an exception with the message "Value cannot be null. Parameter name: name". Is this data stored in a file other than the .csproj? If so, where might I find that data? I've uninstalled and reinstalled sandcastle October CTP, rebooted (a few times), deleted and recreated the project, etc., but to no avail. I'm currently using SHFB, but I never cared much for the NDoc interface, and I don't like any of the 3 standard presentation styles that it renders to. I would really like to get DocProject working, but I think there is a bug in the current release.

Oh, the stack traces are here:

A fatal error occurred while building the project: C:\Storage\Repositories\TFS\PrideEnterprise\Trunk\PrideEnterprise\Pride.Data.Doc\Pride.Data.Doc.csproj.

System.ArgumentNullException: Value cannot be null.
Parameter name: name
at DaveSexton.DocProject.Sandcastle.Configuration.PresentationCollection.get_Item(String name)
at DaveSexton.DocProject.Sandcastle.SandcastleSettings..ctor(IBuildEngine engine)
at DaveSexton.DocProject.Sandcastle.SandcastleBuildEngineProvider.CreateBuildSettings(IBuildEngine engine)
at DaveSexton.DocProject.Engine.BuildEngine`2.get_Settings()
at DaveSexton.DocProject.Engine.BuildEngine`2.Build()
at DaveSexton.DocProject.BuildController.Build(IDocProject project, BuildType buildType)
at DaveSexton.DocProject.BuildController.Build(IDocProject project)
at DaveSexton.DocProject.MSBuild.BuildDocProject.Execute()

Command execution error. Command: ApiTopicDesigner; Tool bar: DocProject - Sandcastle.

System.ArgumentNullException: Value cannot be null.
Parameter name: name
at DaveSexton.DocProject.Sandcastle.Configuration.PresentationCollection.get_Item(String name)
at DaveSexton.DocProject.Sandcastle.SandcastleProjectOptions.ApiTopicDesignerEditor.CreateDialog(SandcastleProjectOptions options, ITypeDescriptorContext context, IServiceProvider provider, Object value)
at DaveSexton.DocProject.DocProjectOptionsDialogEditorBase`2.BeforeEdit(TOptions options, ITypeDescriptorContext context, IServiceProvider provider, Object value)
at DaveSexton.DocProject.DocProjectOptionsEditorBase`1.EditValue(ITypeDescriptorContext context, IServiceProvider provider, Object value)
at DaveSexton.DocProject.DocProjectOptions.ShowPropertyDialog(String propertyName, IServiceProvider provider)
at DaveSexton.DocProject.Sandcastle.ApiTopicDesignerToolBarCommand.Execute(Object option, Object argument)
at DaveSexton.DocProject.ToolBar.Execute(String commandName, vsCommandExecOption option, Object argument, Boolean& handled)
at DaveSexton.DocProject.DocProjectEnvironment.ExecuteCommand(String name, vsCommandExecOption option, Object argument, Boolean& handled)

Command execution error. Command: TopicManagement; Tool bar: DocProject - Sandcastle.

System.ArgumentNullException: Value cannot be null.
Parameter name: name
at DaveSexton.DocProject.Sandcastle.Configuration.PresentationCollection.get_Item(String name)
at DaveSexton.DocProject.Sandcastle.SandcastleSettings..ctor(IBuildEngine engine)
at DaveSexton.DocProject.Sandcastle.SandcastleBuildEngineProvider.CreateBuildSettings(IBuildEngine engine)
at DaveSexton.DocProject.Engine.BuildEngine`2.get_Settings()
at DaveSexton.DocProject.Sandcastle.TopicManagement.ApiTopicManagement..ctor(SandcastleProjectOptions options)
at DaveSexton.DocProject.Sandcastle.SandcastleProjectOptions.ApiTopicManagementEditor.CreateDialog(SandcastleProjectOptions options, ITypeDescriptorContext context, IServiceProvider provider, Object value)
at DaveSexton.DocProject.DocProjectOptionsDialogEditorBase`2.BeforeEdit(TOptions options, ITypeDescriptorContext context, IServiceProvider provider, Object value)
at DaveSexton.DocProject.DocProjectOptionsEditorBase`1.EditValue(ITypeDescriptorContext context, IServiceProvider provider, Object value)
at DaveSexton.DocProject.DocProjectOptions.ShowPropertyDialog(String propertyName, IServiceProvider provider)
at DaveSexton.DocProject.Sandcastle.ApiTopicManagementToolBarCommand.Execute(Object option, Object argument)
at DaveSexton.DocProject.ToolBar.Execute(String commandName, vsCommandExecOption option, Object argument, Boolean& handled)
at DaveSexton.DocProject.DocProjectEnvironment.ExecuteCommand(String name, vsCommandExecOption option, Object argument, Boolean& handled)
Nov 25, 2007 at 9:05 PM
Seems this was related to permissions. I was apparently running Visual Studio as a normal user, not an administrator. Once I reconfigured the shortcut to run as administrator always, the problems went away. Hopefully the run-as-admin issue is solved with VS2008... O_o
Coordinator
Nov 26, 2007 at 5:50 AM
Glad to know that you solved the problem :)

Unfortunately, I'm probably not going to be able to reduce DocProject's permission set though. See this work item for details: Improved Vista Support.

Anyway, here are the answers to the questions that I missed:


Regarding the msbuild project...I thought you were creating your own .build file or something...I'm a big fan of seggregation. :P

Me too, but doesn't it make sense to keep project settings in the project file itself, like other VS project flavors? :)


I found one new thing, with the following markup: [markup snipped].

That markup is meant to contain almost all of the settings for each project, but your project is missing at least one important attribute, which is why you're getting an error. Namely, Sandcastle_PresentationName is missing, which is why the name argument is being passed in as null to the PresentationCollection class's indexer. I'm going to add code that displays a more descriptive error message for this, if possible, even before the New Project Wizard has completed.


Beyond that, I couldn't find any of the settings that appear when I right-click the project node in VS2005, and choose to edit hte DocProject properties (vs. the project properties, which opens up the standard C# project settings document).

What other settings do you expect to see in that markup? Please let me know which properties interest you and I'll let you know where their state is persisted :)

Also, if you check out the preliminary documentation you'll find some answers.

Actually, I'm going to create another work item out of this request for authoring a wiki table that shows the location where user options are persisted. That should also help end-users when new versions of Sandcastle and DocProject become available because, commonly, DocProjects and DocSites become outdated and must be recreated. Knowing where all of the settings are should help, although information about which settings are compatible with the new version is something I guess I'll have to document in the release notes :)


I have been digging around for a while trying to find where the configuration for the property "Version Management: Specify multiple versions for each project reference and external source." is stored.

As I said before, this feature's state is persisted in an XML file found in Help\Settings. It's not going to be there if you aren't using that feature though. Try adding some information to the Version Management dialog and save your changes (click OK). You should see the file appear in Solution Explorer.


Its still causing an exception with the message "Value cannot be null. Parameter name: name".

The stack traces that you posted confirm that Version Management has nothing to do with the error. The problem, as I pointed out originally, is that the presentation name is null and the Version Management property just-so-happens to require a reference to the Presentation class used by the project. The implementation of the Version Management property is rare, in that it attempts to load the version file when the property is first read so that it can display the number of versions in the property grid. But to load the versions file it must have a reference to the Presentation class first so it can determine its location.


I'm currently using SHFB, but I never cared much for the NDoc interface, and I don't like any of the 3 standard presentation styles that it renders to.

Those styles are shipped with Sandcastle though, so they're the only styles in DocProject too. I'm not sure if SHFB allows you to create custom presentation styles (I think it does though), but you definitely can in DocProject if you'd like.

Thanks for the feedback,
Dave
Coordinator
Nov 26, 2007 at 6:01 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Nov 26, 2007 at 6:15 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Nov 26, 2007 at 3:21 PM
Thanks for all the feedback. I've heard a lot of people having problems running Visual Studio 2005 on Vista, but I never had any myself. This weekend was the first time I needed to run VS as administrator to get something working. Its a bit of a conundrum that I really hope Microsoft can solve. With all the security holes available, requiring development tools to have full trust is like telling your dog he has free reign of the refrigerator....only disaster can ensue. :P

Anyway, DocProject is working on Vista at home, and it seems to work great here at work on XP, so I'm set. Thanks for the help.
Coordinator
Nov 26, 2007 at 4:04 PM
I agree with your point about security :)

DocProject, however, may be special in that it requires access to its installation folder under Program Files although its code is executed in Visual Studio's process (devenve.exe, found in an entirely different program files folder, of course), and I believe that requires full trust. I doubt the VS team can do anything about that, although I might be able to if I use the user's profile for DocProject's installation files instead. But that just doesn't seem worth the effort to me due to other areas that require full-trust anyway. For example, DocProject loads an assembly into memory that is found in an entirely different location under program files (e.g., the BuildAssembler.exe program, installed by Sandcastle). I think you get the idea :)

I'm certainly going to keep this in mind for the 2.0 RTW (of DocProject 2008) but it's really not a priority for me now.

- Dave
Dec 14, 2007 at 6:53 PM
Edited Dec 14, 2007 at 7:31 PM

jrista wrote:
Seems this was related to permissions. I was apparently running Visual Studio as a normal user, not an administrator. Once I reconfigured the shortcut to run as administrator always, the problems went away. Hopefully the run-as-admin issue is solved with VS2008... O_o

I have the same issue, but I'm running on Windows 2003 Advanced Server Enterprise with latest fixes/sps. I'm using VS2005. I tried changing the shortcut to run as a different user and used the admin user and that did not help. I tried to also add Everyone with full privileges to the Security and that didn't do anything either. So I'm pretty much stuck right now.

Any other ideas would be greatly appreciated.

EDIT I'll update this as I try the other things mentioned above. I too had the DXROOT in both the user and system environment variables. I removed the one from User as it was pointing to the VS version and kept the System one which is pointing to \program files\sandcastle. Still same issue. I'll report back and put any stack trace results here.
Coordinator
Dec 14, 2007 at 7:57 PM
Hi Prism,

It sounds like your set up is correct now so maybe you've identified a different, but related bug. Those stack traces should help me, if you have any :)

If there are no stack traces, then are you up for attaching the debugger and stepping through the process of creating a new project? I can tell you where to set a breakpoint so that we can see what's going on. For instructions to set up DocProject's solution and attach a debugger to another instance of VS, see How To Use The Source Code.

- Dave
Dec 14, 2007 at 8:16 PM

davedev wrote:
Hi Prism,

It sounds like your set up is correct now so maybe you've identified a different, but related bug. Those stack traces should help me, if you have any :)

If there are no stack traces, then are you up for attaching the debugger and stepping through the process of creating a new project? I can tell you where to set a breakpoint so that we can see what's going on. For instructions to set up DocProject's solution and attach a debugger to another instance of VS, see How To Use The Source Code.

- Dave

Well, you are correct. :) It's working now. The key was closing all instances of VS first. I just created a new project and am running the build now. I'm anxious to see how things turn out. Many thanks. :)