Short version of the problem:
I'm having difficulties including the assemblies my .NET Core Console App depends on.
Initially, the assemblies from NuGet packages were not included in the bin folder even though I could run the app in Debug mode without any problems.
Found an article that suggested that I should add <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in the myapp.csproj file which I did.
Doing so included the dll files for the NuGet packages in the bin folder BUT after I copied my console app to Azure to run as a WebJob, I got an error telling me that System.Data.SqlClient was missing.
After inspecting the folder where the WebJob runs, I could see that the dll for System.Data.SqlClient is actually in the folder. I concluded that it may have been an issue with version numbers. The error indicated the following:
'System.Data.SqlClient', version: '4.4.2' was not found
When I right click the dll file for this assembly and check its version, it shows version 4.6.
Any idea how to resolve this issue?
Longer Version:
I built this .NET Core 2.0 console app to run as a WebJob following this article: http://matt-roberts.me/azure-webjobs-in-net-core-2-with-di-and-configuration/
I had to create this WebJobs app manually because currently Visual Studio does not provide a way to build Azure WebJobs in .NET Core.
Because of this current limitation, I also could not Publish my WebJobs app directly from Visual Studio.
So, I tried to zip it up and upload it through Azure Portal. This is when I realized that NuGet assemblies were not included in the bin folder. The rest of the story is already up in the "Short Version" section.
I'd appreciate some suggestion in solving this issue.
UPDATE:
When I ran dotnet publish --self-contained -r win32-x64 -c Release inside the project's root folder, I got the following error:
Not quite sure of the WebJobs specification, but you should be able to use dotnet publish --self-contained -r win-x64 -c Release to generate executable and its dependencies. Zip them up and you should be able to deploy to Azure.
There is really no need to modify your csproj like you did.
Besides, you can use .NET IL Linker to shrink the size of the generated folder.
Reference
https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli#self-contained-deployment-with-third-party-dependencies
Related
I have a .NET MAUI project that was created with VS2022 Preview 2, and it builds without errors or warnings and works as expected in the debugger. Prior to updating Visual Studio to Version 17.4.0 Preview 4.0 I was able to publish the project as a sideloadable MSIX from within VS.
Since updating, I get the following error when I click Create in the Create App Packages wizard:
MSB4057 The target "_GenerateAppxPackage" does not exist in the project.
The error is listed against the MAUI project's .csproj file.
I've tried creating a separate new, default MAUI project in the new preview - this publishes ok and (as far as I can see) doesn't contain _GenerateAppxPackage anywhere within its files or project structure. So for now I'm assuming this isn't something new that was added with the preview.
I found some references to _GenerateAppxPackage on the web but they appear to refer to Azure integration. My project is a stand-alone data transformation app that doesn't even access the net.
I'm at a loss what to try next. I don't know what this target refers to, where it should "exist" within the project, or what it does. Can anyone help me understand the problem and/or point me to a solution?
Update: 2022-10-28:
I tried deleting the project structure and creating it from scratch with File -> New Project, then adding back only the .cs and .xaml files. Publishing the recreated project gives me the same error.
I also tried uninstalling the VS preview and re-downloading and installing it. Again, publishing the project gives me the same error.
I still have no idea what is causing this, or even where to start looking.
I faced with the same problem at Visual Studio 2022 17.4.0 (net6.0-windows10.0.19041.0).
The simplest solution for me was be using the command dotnet publish directly.
At root of project just write in terminal:
dotnet publish -f net6.0-windows10.0.19041.0 -c /p:RuntimeIdentifierOverride=win10-x64
I learned today that MAUI is now in the mainline Visual Studio 2022 edition, I've tried using that instead of the preview, and I can confirm that the problem goes away. I wish I'd known about this earlier...
Why is it that even though I have the build setting in Visual Studio set to Release everything I create within a side-loaded UWP distribution is placed within a folder with _test on the end? Is it because MS assumes a side-loaded app is always a test app?
I place my appxbundle files within AppCenter and I'm using AppCenter to distrubute our internal production apps to our internal employess using AppCenter.
Here is the main reason I'm even asking. I have tried to publish an appxbundle to the AppCenter for my employees to download and install. Problem is, these target laptops don't have the Microsoft Store installed (don't ask) so the appxbundle won't auto-install. So, when I try to install via a powershell script I can clearly see that the dependency for Microsoft.NET.Native.Runtime.2.0 isn't being met and the install fails. When I extract the appxbundle for my app I see no dependencies are included. But, if I explore the root folder that my app is published to, I can find the Microsoft.NET.Native.Runtime.2.0 is there, it's just not making it into the appxbundle file. In order to install this app on these laptops I have to enable developer mode, I have to zip up the entire published folder, send this zip file to the user, have them extract it, then have them run the powershell script within the root folder. This powershell script installs my appxbundle, cert, and includes all dependencies.
I read HERE the following:
App Center always generates an app bundle. However, Debug builds are
not meant to be used for sideloading. ...and the provided .appxbundle
files in the Test folder do not contain required dependencies.
Since my dependencies are not included within the appxbundle and based on what Microsoft said, it appears my app is being generated as a Debug build even though I'm selecting Release within my IDE before publishing.
Sadly it's hard-coded in the msbuild file "Microsoft.AppxPackage.Targets"
Location for VS2019 C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppxPackage.Targets
Or as MSFT UWP Engineer Nico Zhu said in the comments: "it is by design"
See also: Customizing Visual Studio MSIX packaging project output
I'm attempting to deploy a boilerplate Visual Studio 2017 RC Asp.Net Core web app (no authentication) to an Azure App Service using the GitHub deployment option. The app has not been modified from the boilerplate code; literally: create a new app from the VS template, publish it to GitHub, and deploy to App Service.
Question
Are any particular settings necessary for VS 2017 RC apps to deploy to an App Service, or has the App Service SCM (Kudu) tooling simply not yet caught up with the VS 2017 RC project structure?
Details
I'm running into two problems that I think are probably related.
Problem 1: the MSbuild tools v15.0 don't appear to be installed on the app service. When building, Kudo defaults to v14.0:
Command: "D:\home\site\deployments\tools\deploy.cmd"
Handling .NET Console Application deployment.
MSBuild auto-detection: using msbuild version '14.0' from 'D:\Program Files (x86)\MSBuild\14.0\bin'.
I added a custom app setting, SCM_BUILD_ARGS=-tv:15.0, to try to force Kudo to use v15.0, but this had no effect. It continued to use v14.0 as before.
Problem 2: (and possibly as a result of using MSBuild 14.0): MSBuild issues the following error when attempting to restore NuGet packages:
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
This error message is a little vague, but until recently the message would assert that no project containing a packages.config or project.json file was found in the solution. Both of these files are deprecated as of VS 2017 RC. I added an empty project.json file to see if that would fix the issue. The packages appear to be restored but it continues to fail due to missing project.json sections.
Resolution
#david-ebbo kindly provided guidance. In his test repo you'll find deploy.cmd and .deployment files. Copy both to the root of your repo. Then update Line 74 of deploy.cmd to point to your .csproj file. Deploying from GitHub should now succeed.
Similar to https://github.com/projectkudu/kudu/issues/2236.
The Kudu script generator doesn't yet know how to handle Preview3, but you should be able to use a custom deployment script. The key is to use 'dotnet restore' instead of 'nuget restore' and 'dotnet publish' instead of 'msbuild'. See sample here.
We will fix Kudu to handle this soon.
I am trying to create web application using Visual Studio 2015 and .NET 4.5.1.
When I publish the website, visual studio create folder named roslyn.
I know it's used to compile code on the fly, but unfortunately my hosting provider doesn't allow me to execute the compiler on their server.
How to publish the website without roslyn like previous version of Visual Studio?
EDIT:
I got this error when trying to acces my website.
It seems IIS trying to execute roslyn\csc.exe but my user account doesn't have permission to do that. With previous version of Visual Studio, this error doesn't show up.
I've just faced the same problem. When you create a new web project, two nuget packages automatically added to your project. If you remove them, your problem should be solved. Package names are: "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" and "Microsoft.Net.Compilers".
I had the same issue. Followed the steps from here. Basically:
Uninstall the package
Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform <Your Web API project name>
In your publish profile settings, uncheck "Allow precompiled site to be updatable". You can find this under Settings > Precompile during publishing > configure
After searching the same issued I face, I just came here. I read the above answer which is right.
I give the answer, because of Here is the good article to explain :
Why the publish code have this exe as well as development environment ?
What is the benefit and how to remove?
This is also the very good article, about the history of this exe
After countless effort....and according to this website.
I find that you can use /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false in MSBuild to transform web.config, this also include the roslyn compiler in the build. The output is same as what you get by publishing in Visual Studio into file system
There is an open bug on the roslyn repository about this issue.
In my case all I had to do was to downgrade the dll Microsoft.CodeDom.Providers.DotNetCompilerPlatform from version 1.0.6 to 1.0.5.
I have had the same issue in Sept2016 when I took over an existing ASP.NET program. I found that there were multiple versions of the two compiler packages mentioned by Kemal installed in different projects of the solution.
So firstly I updated to get them the same. VS doesn't tell you that updates are available in this scenario (or maybe I missed them ?)
I then had to restart VS2015 for the packages to clean up properly.
I've been going around and around on this issue. I've got a ASP.NET MVC 3 Web application built in VS2010 SP1. When I attempt to Publish to the local file system, I get the error
The Target "GatherAllFilesToPublish" does not exist in the project.
and it fails. I've followed the answer described in Why do I get the error "The target GatherAllFilesToPublish does not exist"? but it doesn't resolve my problem.
I've installed the Azure SDK 1.8 for VS2010 (October 2012), trying to get my system back to working. With this install, I see the following files/folders in my MSBuild tree.
Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Targets, dated 1/18/2011.
This file does not mention the "GatherAllFilesToPublish"
After installing the Azure SDK, I've got another file/folder:
Microsoft\VisualStudio\v10.5\Web\Microsoft.Web.Publishing.Targets, dated 9/27/2012.
This file does contain the "GatherAllFilesToPublish" target.
Apparently my Publish function in VS2010 isn't using the v10.5 folder's targets. Does anyone have any suggestions to resolve this problem?
Thanks,
And the answer is...
At some point in the past, the project had been edited to include a local copy of the msbuild folder and I had forgotten about it. I used sysinternals' procmon to find the file access and it was only referencing msbuild under my project.
With that, i renamed the folder, edited the csproj file to remove the localized references for the MSBuildExtensionsPath32, and reloaded the project.
I was able to successfully publish my app.