none
VSTO Build Error - invalid value for the "EntryPoint" parameter of the "ResolveManifestFiles" task RRS feed

  • Question

  • The full build error is  

    "bin\Debug\ProjectName.dll;bin\Debug\ProjectName.dll" is an invalid value for the "EntryPoint" parameter of the "ResolveManifestFiles" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem". 

    I'm trying to get working a previous developers VSTO project in Visual Studio 2010 and have resolved all build errors except the above. The project does not have a custom build, just VS default. I don't find anything in the project file that explains why the output DLL path is referenced twice in the error message above.  

    Where can I examine and correct ResolveManifestFiles task?  Thank you.

    Friday, January 8, 2016 9:43 PM

Answers

  • Several years ago when Microsoft was pushing VSTO, I tried it with the idea of making powerful thick client that managers could use to combine network and database resources with interactively with Excel templates. In this app the interaction with databases and external CSV files, as well as populating and formatting Excel reports, all was done from the VSTO vb.net layer, a little bit like a view-model.

    But I found most managers didn't want to master a small learning curve to have flexibility to dynamically define their own queries and report output. So it became a tool for programmers to output the reports for them.

    Since I don't remember the tricks for getting VSTO interop to work on different PCs and newer Visual Studio version, and the nooks and crannies where different functionality can hide, the solution I replaced this with is just to use SSIS to populate tables in stored procedures and call the final output from simple VBA macro in Excel. Just because that's the toolset I'm now familiar with (and seems better supported by MS) that seems simpler to me.

    I hope this helps. Thanks again, I appreciate the quick response.

     

    • Marked as answer by Mark Peacock Wednesday, January 13, 2016 2:07 PM
    Wednesday, January 13, 2016 2:07 PM

All replies

  • Hello Mark,

    Did you have a chance to check out whether such file exists on the disk?

    Saturday, January 9, 2016 12:20 PM
  • Hi Eugene, thanks for your question. Yes the ProjectName.dll exists at bin\Debug.

    The error msg seems to indicate that a semi-colon separated list,  namely "bin\Debug\ProjectName.dll;bin\Debug\ProjectName.dll" isn't a valid parameter. But I don't know where or what file would contain config for "ResolveManifestFiles" task.  No files within the project do.  

    I tried renaming the project & assembly name but the error msg simply changed to reflect the new name (listed twice).

    Saturday, January 9, 2016 6:55 PM
  • Hi Mark,

    Did you add ProjectName.dll reference to your project? Is it a valid COM or Managed Library? If it is COM dll, you need to register the dll.

    For registering dll, you could refer the link below:
    #How to use the Regsvr32 tool and troubleshoot Regsvr32 error messages
    https://support.microsoft.com/en-us/kb/249873

    Here is some information about ResolveManifestFiles.
    # How To: Publish Files Which are not in the Project
    http://blogs.msdn.com/b/mwade/archive/2008/06/29/how-to-publish-files-which-are-not-in-the-project.aspx

    In addition, here is a similar thread which might be useful to you.
    #ResolveManifestFiles build task failed
    https://social.msdn.microsoft.com/Forums/vstudio/en-US/a92bad5e-3a5a-4605-ac2d-03447869892e/resolvemanifestfiles-build-task-failed?forum=vsdebug

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, January 11, 2016 2:30 AM
  • Thanks very much Edward. After experimenting based on ideas in these links, not getting anywhere. 10 years ago I had some Office Interop debugging skills. From current perspective it seems to have so many fragile, obscure and outdated dependencies, I think I'll just re-implement with SSIS.
    Monday, January 11, 2016 3:45 PM
  • Hi Mark,

    I feel sorry that it is not helpful to you, and if you have any issues while re-implement, please feel free to post in this forum.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Tuesday, January 12, 2016 3:02 AM
  • Thanks again, Edward. Much appreciated. I got it working with SSIS, just because I understand that better.
    Tuesday, January 12, 2016 1:04 PM
  • Hi Mark,

    I am glad you got it working. It would be appreciated if you could share us more details solution about working with SSIS, and you could mark it as answer to close this thread. Then others who run into the same issue would find the solution easily.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Wednesday, January 13, 2016 8:16 AM
  • Several years ago when Microsoft was pushing VSTO, I tried it with the idea of making powerful thick client that managers could use to combine network and database resources with interactively with Excel templates. In this app the interaction with databases and external CSV files, as well as populating and formatting Excel reports, all was done from the VSTO vb.net layer, a little bit like a view-model.

    But I found most managers didn't want to master a small learning curve to have flexibility to dynamically define their own queries and report output. So it became a tool for programmers to output the reports for them.

    Since I don't remember the tricks for getting VSTO interop to work on different PCs and newer Visual Studio version, and the nooks and crannies where different functionality can hide, the solution I replaced this with is just to use SSIS to populate tables in stored procedures and call the final output from simple VBA macro in Excel. Just because that's the toolset I'm now familiar with (and seems better supported by MS) that seems simpler to me.

    I hope this helps. Thanks again, I appreciate the quick response.

     

    • Marked as answer by Mark Peacock Wednesday, January 13, 2016 2:07 PM
    Wednesday, January 13, 2016 2:07 PM