ASP .NET Core : Directory.EnumerateFiles and IIS hosting - iis

When I publish my ASP .NET Core (v.2.2) web application on a IIS-server it throws an exception on this line:
Directory.EnumerateFiles(_environment.ContentRootPath + #"/Pages/API")
The exception:
An unhandled exception has occurred while executing the request.
Could not find a part of the path 'C:\Release\MySite\Pages\API'.
System.IO.DirectoryNotFoundException at
System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String
path, Boolean ignoreNotFound)
When I look inside the published folder there is no API folder, but should it not be inside of my website dll? Or can I not use relative or absolute paths to find files in my web project when I publish it on ISS?
Note: The pages in folder API have Build Action : content, and the code works without problem in development (with IIS-express).

For asp.net core, it will precompile views while publishing into Project.Views.dll. For Directory.EnumerateFiles, it only lists the real exist files in the disk.
For a solution, try to modify your project.csproj to add <MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>.
Full
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.2.0" />
</ItemGroup>
</Project>

Related

Why am I getting duplicate errors in my obj/Release/net6.0 folder after building and deploying Azure function in VS Code

My Azure function works, I can debug it, and deploy it no problem. But when I deploy it and it gets built into the release folder I see errors in the obj -> Release/net6.0 folder.
FYI - I deploy by using the Azure extension and in the Azure workspace panel I click on deploy, then choose my resource group and it runs on it's own and deploys no problem.
I'm wondering if it has something to do with the name I gave my project
"Functions" ?
I'll post what I see below.
Here is my .csproj file for the Azure function project
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.0.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.1" />
<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Core\Core.csproj" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Infrastructure\Infrastructure.csproj" />
</ItemGroup>
</Project>
I was having a similar/related problem a week ago (if you ask me to recall it, I'd need to go through heaps of my screenshots). I was able to deploy my Azure function via GitHub but it wouldn't work and I made satisfactory progress by changing (in the Azure Portal) the value of Configuration | Function Runtime Settings | Runtime Version to the value: ~4. However, just today, the portal is warning me to go back to the value: ~3. So, it is just something you might want to try and be prepared to undo.
On a loosely related topic, yesterday I started having problems with deployment again (via GitHub CI/CD). Today, in the Activity Log under a "Sync Web Apps Function Triggers" entry I saw the error: "Encountered an error (BadGateway) from host runtime". A few minutes later it was cleared (and it said it had run for 13 minutes). Now, I'd been in the portal about 15 minutes, so that might have fixed today's issue -- I figured the job was still in the queue and today it was able to pick it up and work it through. By visiting the function in the portal, it must have helped initialize it somehow. Still working on this one. I'll try resetting the Runtime Version value back to the suggested value ~3.
Good luck with your issue. Cheers, Henk.
I have tried replicating your setup (e.g. "Functions" name) on a Mac with Visual Studio details bellow, without any issues however. If you've used any preview version of VS or even Azure Function Extensions, then I suggest you re-create a new project and import your artifacts.
My setup is the following:
Release ID: 1703001972
Git revision: 8eb3c1bb0f14a8e54ee7c227c7047c46cff6ee8c. Build date: 2022-07-12 19:09:28+00
Build branch: release-17.3
Running on .NET 6.0.5 (64-bit)
Operating System: Mac OS X 12.4.0
Darwin 21.5.0 Darwin Kernel Version 21.5.0

How to share parameters configuration between VS publish profile and MSDeploy SetParameters.xml?

I have a web application in Visual Studio 2012. I publish this website to IIS using publish profiles (.pubxml).
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>MSDeploy</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<ExcludeApp_Data>False</ExcludeApp_Data>
<MSDeployServiceURL>server</MSDeployServiceURL>
<DeployIisAppPath>site</DeployIisAppPath>
<RemoteSitePhysicalPath />
<SkipExtraFilesOnServer>False</SkipExtraFilesOnServer>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
<EnableMSDeployBackup>True</EnableMSDeployBackup>
<UserName>domain\username</UserName>
</PropertyGroup>
<ItemGroup>
<MSDeployParameterValue Include="MyParam">
<ParameterValue>MyValue</ParameterValue>
</MSDeployParameterValue>
...
</ItemGroup>
</Project>
Beside I setup a CI to build a package with msbuild and then use it to publish to the different environnement using msdeploy. Both in 2 separates steps, so I can reuse the same package multiple times.
To do this I need to use a SetParameters.xml with a different syntax than the publish profil used by VS.
<?xml version="1.0" encoding="utf-8"?>
<parameters>
<setParameter name="IIS Web Application Name" value="site" />
<setParameter name="MyParam" value="MyValue" />
...
</parameters>
Is there a way to share the parameters configuration in a single file so I can maintain only one file ?
I see this answers from 2014 but I can't managed to make it works.
I've researched this and can't find a way to override the SetParameters file when publish via VisualStudio. It doesn't look like the MSBuild tasks support this.
The best alternative I can offer is to use the commandline instead of right click publish. You can create the MSDeploy package by calling the Package target:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild /t:Package /p:PublishProfile=<profile-name>
And then deploy using MSDeploy.exe:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package=WebApplication7.zip -dest:manifest=WebApplication7.DestManifest.xml -setParamFile:SetParameters.custom.xml
The following blog posts has more details:
https://dotnetcatch.com/2016/02/25/the-anatomy-of-a-webdeploy-package/

Azure: Web.config Connection String' argument cannot be null or empty

When I try to publish an azure app I get this error.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4283,5): Error : The 'ibasis_Data_Transfer.mytestdbEntities-Web.config Connection String' argument cannot be null or empty.
My App.Config has a connection string. e.g.
<add name="mytestdbEntities" connectionString="metadata=res://*/mytestappModel.csdl|res://*/mytestappModel.ssdl|res://*/mytestappModel.msl;provider=System.Data.SqlClient;provider connection string="data source=tcp:srv-mytestapp-home.database.windows.net,1433;initial catalog=mytestdb;persist security info=True;user id=blabla;password=blabla;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
Don't know where to start looking for solution as error not mentioned on web anywhere in relation to azure.
ibasis - Web Deploy.pubxml
<?xml version="1.0" encoding="utf-8" ?>
<!--
This file is used by the publish/package process of your Web project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit http://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>MSDeploy</WebPublishMethod>
<PublishProvider>AzureWebSite</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish>http://ibasis.azurewebsites.net</SiteUrlToLaunchAfterPublish>
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<MSDeployServiceURL>ibasis.scm.azurewebsites.net:443</MSDeployServiceURL>
<DeployIisAppPath>ibasis</DeployIisAppPath>
<SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
<UserName>$ibasis</UserName>
<_SavePWD>True</_SavePWD>
<_DestinationType>AzureWebSite</_DestinationType>
<PublishDatabaseSettings>
<Objects xmlns="">
<ObjectGroup Name="ibasis_Data_Transfer.ibasisLiveEntities" Order="1" Enabled="False">
<Destination Path="" />
<Object Type="DbCodeFirst">
<Source Path="DBContext" DbContext="ibasis_Data_Transfer.ibasisLiveEntities, ibasis-Data-Transfer" />
</Object>
</ObjectGroup>
</Objects>
</PublishDatabaseSettings>
</PropertyGroup>
<ItemGroup>
<MSDeployParameterValue Include="$(DeployParameterPrefix)ibasis_Data_Transfer.ibasisLiveEntities-Web.config Connection String" />
</ItemGroup>
<ItemGroup>
<_ConnectionStringsToInsert Include="ibasis_Data_Transfer.ibasisLiveEntities" />
</ItemGroup>
</Project>
Update: As far as i can tell the VS publishing of simple Apps to Azure with 'database first' type entity(edmx) files is not possible.
The auto generated ....Web Deploy.pubxml gets filled with incompatible junk like and "DeployParameterPrefix" which can't be removed and break the build.
I only wanted to call simple Stored Procedure e.g.
myappLiveEntities db = new myappLiveEntities();
db.DoSomeDatabaseWork();
Will do it "old school" method.
I ran into this with a webjob I had been deploying successfully. I wound up deleting the pubxml file under the webjob project PublishProfiles folder and redoing the publish As Azure WebJob.
This issue popped up again when I upgraded to this specific nuget package:
"Microsoft.WindowsAzure.ConfigurationManager" version="3.2.3"
It may be an issue with publishing the webjob before publishing the updated web app or editing the WebApp publish settings ...
Edit: I've since switched to including the web job to the web app publish settings. You can do this by right clicking the project and choosing Add -> Existing Project as Azure Web Job. I no longer publish the WebJob separately.
I believe you need to add a ParameterValue under the MSDeployParameterValue list item. For example,
<ItemGroup>
<MSDeployParameterValue Include="Parameter Name">
<ParameterValue>Parameter Value</ParameterValue>
</MSDeployParameterValue>
</ItemGroup>

Continuous integration AND NuGet restore in VSO and Azure

We are using VSO and Azure Cloud Services (web roles).
Previously, we have used the following build.proj file for our VSO build definitions:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OutDir>$(MSBuildThisFileDirectory)bin</OutDir>
<Configuration>Release</Configuration>
<ProjectProperties>OutDir=$(OutDir);Configuration=$(Configuration);</ProjectProperties>
</PropertyGroup>
<ItemGroup>
<Solution Include="$(MSBuildThisFileDirectory)*.sln" />
</ItemGroup>
<Target Name="RestorePackages">
<Exec Command=""$(MSBuildThisFileDirectory).nuget\NuGet.exe" restore "%(Solution.Identity)"" />
</Target>
<Target Name="Clean">
<MSBuild Targets="Clean" Projects="#(Solution)" Properties="$(ProjectProperties)" />
</Target>
<Target Name="Build" DependsOnTargets="RestorePackages">
<MSBuild Targets="Build" Projects="#(Solution)" Properties="$(ProjectProperties)" />
</Target>
<Target Name="Rebuild" DependsOnTargets="RestorePackages">
<MSBuild Targets="Rebuild" Projects="#(Solution)" Properties="$(ProjectProperties)" />
</Target>
</Project>
The reason for this is to execute NuGet restore before MSBuild began running. This is a suggested approach by NuGet.
Now that we are trying to set up continuous integration with our Azure cloud services, as instructed in this MSDN article.
This means that we must now use the TfvcContinuousDeploymentTemplate.12.xml build process template.
But when setting the template to build the build.proj file, the following build error occurs:
Exception Message: Deploying to Azure Cloud Service requires a Visual Studio Solution (.sln) that contains either a ccproj or a lsxproj. (type DeploymentException)
Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
When using the .sln, all works fine. But we obviously also need NuGet restore to occur before the build.
What is a good solution to have both continuous integration AND NuGet restore working?
I have just learnt that this is redundant. There is no reason to manually execute NuGet restore as this is already built into VSO/TFS.
Read more here.

CopyAllFilesToSingleFolderForMsdeployDependsOn hook works on local but not when built in TFS

With reference to this article by SamStephens and this by Sayed, I have managed to include additional dependent files during packaging when built LOCALLY using Visual Studio 2012.
The issue starts when I built the codes in TFS. Looking through the logs, it looks like the CopyAllFilesToSingleFolderForMsdeployDependsOn is not hooked on.
CopyAllFilesToSingleFolderForMsdeployDependsOn =
;
;
CopyAllFilesToSingleFolderForPackageDependsOn =
;
;
So I have a Deployment.csproj with a CreatePackage.targets file and in this target file, it would build the web application project. The following is the snippet of the file which I combine what I learned from both the articles stated earlier.
<!-- Create Web Deploy package for local build. -->
<Target Name="WebPackage" Condition="'$(TfsBuild)' == ''">
<!-- MSBuild the project. -->
<MSBuild Projects="..\webapplication.csproj"
Targets="Package"
Properties="
Platform=$(Platform);
VisualStudioVersion=$(VisualStudioVersion);
Configuration=$(Configuration);
WebPublishMethod=Package;
ExcludeApp_Data=false;
DeployOnBuild=true;
DeployTarget=Package;
PackageAsSingleFile=true;
PackageLocation=$(PackageOutputDirectory);
PublishProfile=$(MSBuildThisFileFullPath);
ExcludeFoldersFromDeployment=Scripts;
ExcludeFilesFromDeployment=parameters.xml;">
</MSBuild>
</Target>
<PropertyGroup>
<CopyAllFilesToSingleFolderForMsdeployDependsOn>
DefineAssemblies;
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForMsdeployDependsOn);
</CopyAllFilesToSingleFolderForMsdeployDependsOn>
<AssemblySource Condition="'$(TfsBuild)' == ''">$(SolutionDir)\ProjectA\bin\$(Configuration)\ProjectA.dll</AssemblySource>
<AssemblySource Condition="'$(TfsBuild)' == 'true'">$(OutputDirectory)ProjectA.dll</AssemblySource>
<Target Name="DefineAssemblies">
<ItemGroup>
<FilesToInclude Include="$(AssemblySource)">
<Dir>lib</Dir>
</FilesToInclude >
</ItemGroup>
</Target>
<Target Name="CustomCollectFiles">
<ItemGroup>
<FilesForPackagingFromProject Include="#(FilesToInclude )">
<DestinationRelativePath>%(FilesToInclude.Dir)\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
So the question is: Why is this working nicely locally in VS2012 and not in the TFS build?
I've been stuck in this for two days now so I would really appreciate any help.

Resources