We Keep Coding

Installing ASP .NET Core service to IIS using Visual Studio Installer Projects

I have a ASP .NET Core 3.1 application which is hosted as a windows service using IHostBuilder.UseWindowsService call. I am preparing a setup project using Visual Studio Installer Projects Extensions. The project is created as Web Setup project type so that the installer dialog already presents to the user selection of web page and application pool on IIS.
The problem I'm facing is that the assemblies are successfully installed in given folder on IIS, but the ApplicationService.deps.json is not installed. Without this file the application does not start successfully. As far as I have checked the file is created as part of the build in bin\x64\Release\netcoreapp3.1\ but is apparently not included by the Setup project.
I've played around also with Setup project's property PublishProfilePath by specify the profile that I generated when manually trying to publish from Visual Studio to IIS:
However, this produces even stranger results. The application is deployed to the IIS already when I build the Setup project! Then when check the newly created msi, it's size is really small and in fact does not install anything (completes successfully though).
Any help would be highly appreciated.

I managed to solve the problem, though I'm not sure if that's the optimal solution. In the setup project, you can include as part of the output also individual files. If I add the ApplicationService.deps.json it is marked with a relative path in the setup project itself. This means that once setup project is being build, the ApplicationService project is anyway built first as it's the primary output of setup project. At that point `ApplicationService.deps.json' is present in the Release folder. Then as msi is being created it's included as part of the output.
It works, but I would prefer that the setup project would include that file automatically.

Will the code in Azure change for the web app bot when published from VS?

I've published the code from Visual studio, but I don't see the code changes that I made for the bot reflecting anywhere in the azure online editor. Will the code get changed or not ?

Assuming the publishing configuration is publishing to the correct location and no errors occurring, then it should publish the changed/added code to the Azure Web App. Also, it depends on what (files) exactly you are looking at. Any code changes should be represented in a date change in the .dll that gets published. Other files, depend on what types they are. You can check the properties in Visual Studio to see if Copy to Output Directory to see if it will be added to the output folder and published.

publish two projects in same solution

I am currently running into an issue where I have an mvc project and an API project in the same solution,Visual Studio 2017.
when I build the solution the structure is as follows
solution
solution/area1
solution/area2
solution/api
I am able to reach the api with no issues when just building on my local machine, but when I go to publish the solution the api project builds the dlls but does not build out the solution/api so I cannot navigate to my api calls.
I have tried setting up multiple start up solutions which did not resolve the issue.

When you build on your local machine, you probably use '(Re)Build solution', which builds all projects in the solution.
However, there is no such thing as 'Publish solution'. You can only publish a Project. When you do that, only the project and all its dependencies are built & published.
if your API is in a seperate project and not referenced from the MVC site, it will not be built nor published together with that MVC application.
There are two viable approaches:
You integrate the API in the MVC site (same domain, same routing mechanism, probably seperate area).
In that case I would suggest keeping it in the same project for simplicity.
You develop the API as a seperate application in its own (sub)domain.
Here you put it in its own project. And you build and publish it on its own, seperate from the MVC application.

msbuild MyProject.csproj /p:DeployOnBuild=true;PublishProfile=<profile-name>;Password=<insert-password>
https://stackoverflow.com/a/14232754/2183503 has the answer.
Note: It has some spurious information (regarding passing vs version) though. For example, I tested the command out out just now and it worked fine without the /p:VisualStudioVersion=11.0 in Visual Studio 2019 Developer Command Prompt.

Downloading a bot created on the portal leads to an invalid/unrunable solution

I went to the Azure Portal to try out the Bot Framework. I followed the steps and created a Proactive bot.
Without changing anything, I went to Configure continuous integration and downloaded the zip file.
When I try to open that SLN file in Visual Studio 2015 I get the following error when opening the solution:
The Output window shows this in the Solution dropdown:
Some of the properties associated with the solution could not be read.
Here's a screenshot of the Solution Explorer:
Then I press F5 to test it out...
Is it supposed to be running? Am I supposed to do something?

EDIT:
Locally debugging Azure Function apps (which is the type of application created by the Bot Service) is somewhat complex at this time. The process is also undergoing changes between the Azure SDK 2.9.6 and 3.0. The tooling for VS2017 is also undergoing some changes: .NET Web Development and Tools Blog
Update 3-10-2017: This preview copy of Azure Functions Tools does not
work with the newly released Azure SDK 3.0. If you want to continue
using these tools on Visual Studio 2015, you will need to remain on
the 2.9.6 SDK. Additionally, there are no Azure Function Tools
currently available for Visual Studio 2017. We are actively working
on the 2017 tools, and will provide an update in the next few weeks
regarding our plans and strategy.
This blog post by Benjamin Perkins has a nice walk through: https://blogs.msdn.microsoft.com/benjaminperkins/2016/12/01/how-i-tested-my-chatbot-that-i-created-using-the-bot-services-on-azure/
There's also this : Debugging Bots Built using Azure Bot Service on Windows
The C# environment in Azure Bot Service has more in common with
Node.js than a typical C# app because it requires a runtime host, much
like the Node engine. In Azure, the runtime is part of the hosting
environment in the cloud, but you’ll need to replicate that
environment locally on your desktop.
First, you need to set up your environment. You’ll need:
A local copy of your Azure Bot Service code (see Setting up Continuous Integration )
The Bot Framework Emulator
The Azure Functions CLI
DotNet CLI
and if you want breakpoint debugging in Visual Studio 15:
Visual Studio 15—the Community Edition will work fine
The Command Task Runner Visual Studio Extension
After installing the tools above, you have everything you need to
debug your C# bot locally.
Open a command prompt and navigate to the folder where your
project.json file lives in your repository. Issue the command dotnet
restore to restore the various packages referenced in your bot.
Note: Visual Studio 2017 RC is changing how it handles dependencies
from a project.json to a .csproj model when loading in Visual Studio.
As a result, you will need to download the csproj here:
https://aka.ms/bf-debug-project and save the .csproj into your
/repo/messages folder before running the dotnet restore command.
Note these are also requirements:
Azure 2.9.6 .NET SDK
Visual Studio Tools for Azure Functions
And there's this: https://blogs.msdn.microsoft.com/appserviceteam/2017/03/16/publishing-a-net-class-library-as-a-function-app/ you will find a description of how to publish a function app from visual studio, and how to download and execute an existing function app in visual studio.
Install the Azure Functions CLI from npm.
If you’ve installed the Visual Studio Tools for Azure Functions, just add func.exe to your path from %USERPROFILE%\AppData\Local\Azure.Functions.Cli\1.0.0-beta.93 (or the latest version on your machine).
Go to the Kudu console for your Function App in Function App Settings -> Kudu. Navigate to site and click on the download icon to the left of wwwroot (click on the animated gif below). Or, from an authenticated session, go to https://[YOURFUNCTIONAPP].scm.azurewebsites.net/api/zip/site/wwwroot/.
Unzip the file wwwroot.zip on your local machine. From that directory, run the following:
func azure login
func azure functionapp list
func azure functionapp fetch-app-settings [name]
This will create a local file called appsettings.json. These settings
are only used locally by the Functions CLI. Since this file contains
secrets, be sure not to check this file in to source control! (The
Azure Functions CLI adds appsettings.json to .gitignore for you.)
Copy your downloaded files to the web project folder (including
appsettings.json). Include the script files and function.json in the
project. F5 should now work and successfully attach a debugger.

ASP.net Web Application project maintaining release and builds

We are a small team, working on a ASP.net Web Application project, following is the solution structure,
Solution:
Project: Data Access Layer
Project: Model Layer
Project: Business Layer
Project: Web Application Project
For source code repository, we are using Visual Studio Online, since team is small so we are using the Free version.
We are now trying to maintain the proper version for each release. Currently we publish (using publish tool Visual Studio) in a folder, then manually copy and paste files on server Website folder. So right now, the web application's DLL file is having version 1.0.0.0 all the time.
Now we want to use the VSO Build Feature, and each time when we run the build, we want this to happen.
Compiled website
Full code should (all projects) also be copied along with published files
The website DLL's build number should be increased automatically
I am NOT sure if all the above can be done on build or is there any other procedure. Can someone please point us in the right direction?
Thanks.

That can all be fine with the build on VSO. If you are using the XAML build you don't need anything else. Just configured a new build and out It at your solution. You will then get versioned output. To get the build output to have the version number incremented you will need to use powershell and call that during the build.
http://www.codewrecks.com/blog/index.php/2014/01/11/customize-tfs-2013-build-with-powershell-scripts/