aspnet / Tooling

Issue tracker and info on Visual Studio tooling for ASP.NET
Other
256 stars 124 forks source link

VS2017 RC - The target “GetCopyToPublishDirectoryItems” does not exist in the project. #869

Closed delie closed 7 years ago

delie commented 7 years ago

After installing Visual Studio 2017 RC, and upgrading my ASP.NET Core Web Application (.NET Framework) project to CSPROJ, I am no longer able to publish my project to the file system. Building the solution works fine, but when I publish I get this error:

The target "GetCopyToPublishDirectoryItems" does not exist in the project.

To replicate:

  1. Create a new ASP.NET Core Project (.NET Framework), and solution.
  2. Add a new Class Library project (.NET Framework) to the solution.
  3. Reference the Class Library project in the .NET Core project.
  4. Instantiate a class from the Class Library project in the .NET Core project
  5. Rebuild solution.
  6. Publish the .NET Core project and it throws the error.
discostu105 commented 7 years ago

I have exactly the same problem.

btw, "GetCopyToPublishDirectoryItems" is defined over there: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Publish.targets

Maybe @eerhardt knows something about that? Is there a workaround? I'm trying to port my project to .csproj, but this blocks me.

duracellko commented 7 years ago

I tried workaround to add empty target to referenced class library project:

It helped a bit, but then I encountered another error. It is mentioned in known issues. https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md "Unable to publish"

I tried to find a workaround by overriding some targets. After few hours I gave up and I converted project to standard .NET Framework Console Application.

  1. Delete old project (make a backup of course).
  2. Create new project using template Classic Windows - Console applications.
  3. Add same NuGet packages as in old project.
  4. Add all *.cs files from old project.
  5. Add references to class library project.
  6. Open WebApp.csproj in text editor.
  7. Add following element at the end of file.
  <Target Name="AfterBuild">
    <Copy SourceFiles="$(SolutionDir)\packages\Libuv.1.9.1\runtimes\win7-x64\native\libuv.dll" DestinationFolder="$(TargetDir)" />
  </Target>
  1. Add following element into App.config
<runtime>
 <gcServer enabled="true" />
</runtime>
  1. Add Web.config from old project.
  2. In Web.config change attribute aspNetCore/processPath to name of console application executable (WebApp.exe) and change arguments to empty string.

If you use different configuration in development environment, I added command line argument for debug project -AspNetCore:Environment=Development, then in Program.Main method I transformed this command line arguments to environment variable ASPNETCORE_ENVIRONMENT.

If you use User Secrets, then add into .csproj file element <UserSecretsId>YourSecretId</UserSecretsId>. Then you have to add secrets.json file to you AppData profile. No support from Visual Studio in this.

duracellko commented 7 years ago

And I forgot to set Copy to Output Directory for files web.config and appsettings.json.

My project is just WebAPI, so no .cshtml file. So it's easy.

hybridview commented 7 years ago

This issue doesn't appear to have gotten any attention yet. Does anymore know why it happens? I'm trying to find a workaround without having to hack up my project file.

jsgoupil commented 7 years ago

@hybridview Rolling back to WebAPI2 was the best solution I have done so far.

eerhardt commented 7 years ago

Sorry, I've been on vacation and haven't been checking email or GitHub. I just saw this now.

The problem is that one project uses the new Microsoft.NET.Sdk project system and the referenced class library project doesn't use the same project system.

As a workaround, I can think of the following options:

  1. Convert the class library project to use the new Microsoft.NET.Sdk project system.
  2. Add a "fake/mock" empty target to your class library project named "GetCopyToPublishDirectoryItems". This is mostly a hack, but it should get by the error mentioned above. You may run into other issues once you get by this error.

@srivatsn - Is it a supported scenario to mix and match these different project systems across P2P references?

/cc @nguerrera @dsplaisted @davkean

davkean commented 7 years ago

Yes this is supported. Either we dummy out GetCopyToPublishDirectoryItems or sniff that the target doesn't exist (not sure this is even possible)?

srivatsn commented 7 years ago

Yes referencing an existing project from a new one is supported.

coonmoo commented 7 years ago

I have the same problem with Service Fabric, Asp.Net Core and VS 2017 RC2.

To replicate:

  1. Create a new Service Fabric project
  2. Select ASP.NET Core Web
  3. Add a new Class Library project (.NET Framework) to the solution.
  4. Reference the Class Library project in the .NET Core project.
  5. Instantiate a class from the Class Library project in the .NET Core project
  6. Rebuild solution.
  7. Publish the Service Fabric project

I'd love to see a fix for this, because VS 2017 is awesome.

Register-ServiceFabricApplicationType : The BuildLayout of the application in 
4>C:\SfDevCluster\Data\ImageBuilderProxy\AppType\SfApplication1Type is invalid. Code is missing for service Web1Pkg.
4>At C:\Program Files\Microsoft SDKs\Service 
4>Fabric\Tools\PSModule\ServiceFabricSDK\Publish-NewServiceFabricApplication.ps1:244 char:9
4>+         Register-ServiceFabricApplicationType -ApplicationPathInImage ...
4>+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4>    + CategoryInfo          : InvalidOperation: (Microsoft.Servi...usterConnection:ClusterConnection) [Register-Servic 
4>   eFabricApplicationType], FabricException
4>    + FullyQualifiedErrorId : RegisterApplicationTypeErrorId,Microsoft.ServiceFabric.Powershell.RegisterApplicationTyp 
4>   e
4> 
4>Finished executing script 'Deploy-FabricApplication.ps1'.
4>Time elapsed: 00:00:12.3127633
4>The PowerShell script failed to execute.
dsplaisted commented 7 years ago

@srivatsn We should move this issue to the dotnet/sdk repo. I don't think we currently have tests that cover building an SDK project which references a non-SDK project, much less publishing in this scenario.

EuroForm commented 7 years ago

Having same problem. Would also love to see a fix to this 😅🙏🔥

srivatsn commented 7 years ago

This issue was moved to dotnet/sdk#543