Why can't I open my Azure Bot Service in Visual Studio? - azure

Okay, so this problem is kinda complicated, but I'll try to make it as simple as possible.
So I have this Bot Service created in Microsoft's Azure platform. It's been hooked up to BitBucket with the continuous integration option. Then, I tried following the instructions here in order to be able to debug the bot locally with Visual Studio. I downloaded and installed all the requisite tools and pulled the BitBucket project into a local repository. However, when I tried running 'dotnet restore' in the messages folder, I received this error message:
C:\...\messages\project.json(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.
This project.json file was automatically built by Azure; why should it be invalid? The contents look like this:
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.Bot.Builder.Azure": "3.1"
}
}
}
}
I've also tried the same thing with Visual Studio 2017, this time including the messages.csproj file in the messages folder. And this time, dotnet restore said I needed to specify a project/solution file because there multiple in the folder. I dunno if that's necessarily a problem, but it's not mentioned at all in the official guide, so it's at least a bit suspicious. Anyway, specifying project.json leads to the same error, while specifying messages.csproj seems to work all right and outputs this:
NuGet Config files used:
C:\Users\Connor.Johnson\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config
Feeds used:
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
That being the case, I run debughost.cmd. Previously, I had to manually copy over project.lock.json from the downloadable zip file available on Azure (it's in gitignore) as the debughost thing wouldn't automatically restore that stuff. More recently that doesn't seem to be a problem any more. Anyway, the debughost.cmd stuff works fine.
Naw, the real problem's when I try to open this stuff in Visual Studio. See, when I try to open the bot.sln file, I get this error message:
One or more projects in the solution were not loaded correctly. Please see the Output Window for more details.
Okay, so the Output Window gives me this super useful information:
Some of the properties associated with the solution could not be read.
Uh huh... Well, in terms of what shows up in Visual Studio, only debughost.cmd, commands.json, and readme.md show up. The messages folder is there, but it's empty. There's also an Azure Functions func thing. That's it.
Now I've looked all over for information on this issue, but I'm apparently the only person who's had it. Moreover, I've tried opening the Bot in VS2015, VS2017, from only the source code downloaded from Azure (i.e., without the Git stuff), and from the BitBucket repository. I've also tried using connecting to source control from the Team Explorer in Visual Studio. Nothing's working! I can't find any information on what might be incorrectly configured, and I find it odd that I should have to change anything. I could serrrrrrriously use some help here.

Related

Azure Functions Core tools suddenly stopped working

I was in the middle of working on some minor code changes when all of a sudden I started getting the following error on startup:
A host error has occurred during startup operation '78d5d8fd-e81c-4707-87ca-6b801430fef1'.
[2021-01-08T13:02:40.279Z] System.IO.FileSystem: Could not find a part of the path 'C:\Users\schiefaw\AppData\Local\AzureFunctionsTools\Releases\3.17.0\workers'.
I looked at the path and found everything exists until I get to "workers".
I, of course, assumed it was something I did, so I backed out all changes to no effect. Then I uninstalled visual studio and all Azure products I could find and reinstalled to no effect. I created a new user (since the file it is looking for is in my user folder) to no effect.
I then created an entirely new instance of a windows virtual machine and installed the development environment to no effect (same error).
I am completely stuck on this. Does anyone have any ideas on what I can try next?
Thanks!
I think this is a bug from that 3.17 release. But here is a work-around: you can add the "workers" folder (empty folder) and it should work. Another way if you have a copy of the previous version (such as 3.16.x), you can copy the content to the 3.17.0 one.
You can read more here: https://developercommunity.visualstudio.com/content/problem/1304718/azure-functions-local-debugging-broke-with-3170-up.html

How to build .sqlproj requiring SSDT in a linux docker container?

I want to build a .sqlproj inside a linux container. The problem is that building the .sqlproj is dependent on SSDT and so far I can't find SSDT that can be installed as standalone on linux.
Error I see running 'dotnet msbuild' in my container:
error MSB4019: The imported project "/usr/share/dotnet/sdk/2.2.402/Microsoft/VisualStudio/v11.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Searching the .sqlproj file for the issue, I see we are trying to import a Schema.SqlTasks.targets file, which I'm assuming SSDT creates:
<Import Condition="'$(SQLDBExtensionsRefPath)' == ''" Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
I see the same error testing out 'dotnet build'
There is a Windows standalone option:
https://learn.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?redirectedfrom=MSDN&view=sql-server-ver15
https://www.nuget.org/packages/Microsoft.Data.Tools.Msbuild/10.0.61804.210
Has anyone found a way to provide SSDT in a linux container?
Goal State: The build step to generate the dacpacs would occur inside the container.
Current State: For now I'm using Visual Studio on my machine as the build machine, then copying the dacpacs up to the container where sqlpackage.exe can then publish the schema.
Why Linux? This dockerized DB will support a stack of services running in linux containers, so a windows container is not ideal.
Ok, so with a bit of help from ErikEJ and other members of the community, at the GitHub link given to you by Brett Rowberry in the comments, I finally figured out how to do this.
The steps to follow are quite simple.
Add your SQL Server project
Add a .NET standard class library project and call it something like "database.build"
remove all the code from the class library project, and modify the csproj file so it reads something like the following
Change the properties on your solution so as to NOT build the sql server project for all configurations.
Once you done this, you'll find that you still get access to the SQL database project in visual studio, and get all the syntax highlighting and intellisense, but your CI will build the SQL code via the linked class library and produce a dacpac in it's output folder ready to be deployed.
Right clicking on the project will allow you to build it from within Visual Studio, and right clicking and selecting "Publish" will allow you to specify your database parameters and publish it to the DB server being used. If you have other objects already in your database that you need to reference, you can create an object only dacpac from the database, using SQL server management studio, which you can then add to your project and check in with it's sources so that you do not need to recreate every single object you may already have.
I've written a blog post explaining it all at length here:
https://shawtyds.wordpress.com/2020/08/26/using-a-full-framework-sql-server-project-in-a-net-core-project-build/
I had the same issue what I did as a workaround:
1- Generated sql script from database project "Generate Script"
2- Followed this code sample to run the script on the Linux container
https://github.com/microsoft/mssql-docker/issues/2#issuecomment-547699532
https://github.com/lkurzyniec/netcore-boilerplate/tree/master/db/mssql
https://github.com/lkurzyniec/netcore-boilerplate/blob/master/docker-compose.yml

Can't publish a dummy F# Suave app as an Azure WebApp. What am I doing wrong?

The project was generated through Ionide and Visual Studio Code. I'm deploying to an Azure WebApp through GitHub.
The GitHub repository is: https://github.com/laygr/suave-dummy
The activity log says:
Command: build.cmd
The system cannot find the path specified.
�
The system cannot find the path specified.
D:\Program Files (x86)\SiteExtensions\Kudu\59.51109.2534\bin\Scripts\starter.cmd build.cmd
It is as simple as a Suave app gets. I hope that this can help others.
Edit
After restarting fresh again (new repo, new web app, new day, new hopes), azure showed a different error which allowed me to figure out the rest. I'll leave the repo so that anyone can see how to deploy the simplest Suave app as an Azure Web App through GitHub
So, after an improvement on the error shown by Azure, I could figure out how to deploy the app.
I had to:
remove .exe from the .gitignore generated by Ionide for Visual Studio Code.
create .deployment
create web.config
modify the build.cmd (I copied it from somewhere else)
modify the build.fsx to perform the correct build
modify the startup file (suave-dummy.fs) to use the correct port
Feel free to check the repo to see what I mean in code. Relevant files:
.gitignore
.deployment
suave-dummy\WebHost\web.config
build.cmd
build.fsx
suave-dummy\suave-dummy.fs
phew!

Unable to publish node js site to azure using Visual Studio 2013

I am publishing my node js site to azure using this tutorial - http://blogs.technet.com/b/sams_blog/archive/2014/11/14/azure-websites-deploy-node-js-website-using-visual-studio.aspx
I get the following error, as mentioned in one of the comments on the blog, any idea what this error is about and how do I fix this ? I am able to run my app locally no issues with that.
Error: InvalidParameter
Parameter name: index
P.s : the site is like a very basic "Hello world" kind of site, this is the first time I am using and deploying to azure too.
I created a new project as a "Blank Azure Node.js web application", and replaced the resulting package.json and .js files with what I had before, and it publishes fine now
All was working fine for and suddenly got the error! I pretty sure it something in the project as it's now happening on vs2013 and vs2015 on different computers.
Its something to do with Templates after a lot of searching. For me Azure TFS CI got things working again if possible for you?
I had this issue with some projects but not with others, all created in a similar way. So I went thought every change and every setting I could until eventually i worked it out. I didn't want to give up and just remake them.
Basically its file paths, the first thing you notice is that it errors very quickly compared to a usual publish, the first thing that is triggered is a build but unlike heavy framework languages there not really much to actually build.
Like all builds for VS it pops out a bin folder take not of where this appears. This is the key, you want this to appear in the root of your deployment usually at the same level as the publish profile.
Before I moved my projects to VS, TFS and Azure, I used to use git and used the azure push and deployment as part of git, so I instinctively structured my folders in the similar fashion with src folder and all the extra VS baggage in the a directory higher.
This is where I noticed bin folder, so re-structured my solution and made changes to .njsproj (notepad) and moved to be inline with source code and re-added it yo my solution.
Technically speaking this a bug within VS as it allows to create the project and specify different locations which is all fine unless you want to build and publish locally.
Once you get your head around what is going on you should be able to solve this problem easily and not make the same mistake in the future. If anyone is still confused comment and ill grab some screen shots.

Publishing vs2012 solution from TeamCity

I'm using Visual Studio 2012 and the publishing feature. I have created a publishing profile that deploys my application to a development server, and it works great when executed from vs2012 on my machine. Here is my problem; on the development server I also have TeamCity installed and I would like to trigger the publishing after a build have completed. So I created a simple build step that looks like this:
Build file path: .\src\Solution.sln
Targets: Rebuild
Command line parameters: /p:DeployOnBuild=true;PublishProfile=Ci
When this step is executing I get the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4377, 5): error ERROR_USER_NOT_ADMIN: Web deployment task failed.
(Connected to 'dev.domain.com' using the Web Deployment Agent Service, but could not authorize. Make sure you are an administrator on 'dev.domain.com'.
The Ci profile contains a username and password that works when I run the publishing from Visual Studio on my machine. I have also tried passing in username and password as parameters in the build step, but I get the same result. Do I need to run the TeamCity services under admin accounts to get this working? All suggestions are appreciated.
I have just blogged about this at http://sedodream.com/2013/01/06/CommandLineWebProjectPublishing.aspx.
You are pretty close, hopefully I can close the gap.
You are correct that username and password are specified in the VS publish dialog, but we do not save the password in the .pubxml file. It is currently being saved in the .pubxml.user file, and that file is not used at all for command line scenarios. Because of that you will need to pass in the property. So in your case it should be
msbuild .\src\solution.sln /p:DeployOnBuild=true /p:PublishProfile=ci /p:Password=<insert-password>
If your web server does not have trusted certs you may need to also pass in /p:AllowUntrustedCertificate=true.
One little addition which may not be directly related to your issue, but may be helpful for others which may see this later.
If you are building the .csproj/.vbproj file (and potentially in some scenarios where the .sln file is used) you should pass in the property /p:VisualStudioVersion=11.0. More info on this available at my blog http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx

Resources