I have added a new default ASP.NET 5 web app, and chosen to deploy to AZURE. This works fine, but if I retry and add a azure sql db, then I get the error below as it tries to create the new resource group.
Microsoft Visual Studio
Template deployment failed. Deployment operation statuses:
Failed: /subscriptions/81368473107b/resourceGroups/DJWTestDb/providers/Microsoft.Sql/servers/djwtestdbdbserver ()
error (InvalidApiVersionParameter): The api-version '2.0' is invalid. The api version must be of the following format: yyyy-MM-dd. This format supports the following suffixes: '-preview,-alpha,-beta,-rc,-privatepreview'.
Succeeded: /subscriptions/81368473107b/resourceGroups/DJWTestDb/providers/Microsoft.Web/serverfarms/DJWTestDbPlan ()
I've been running into the same problem, just registered to let you know. It seems that it isn't possible right now (who knows why, but I'm looking at you, ASP.NET RC1) to publish while deploying an SQL server. However, it DOES work to publish without one and make one in the portal, and then connect them through your Web.config.
At first I thought it was all of the new updates to Visual Studio (as of 5/12/15), but I was still getting the same problems after updating. I'm not sure if the new updates are required for this workaround, but that's what I was working with for this.
Steps:
1. Publish your API app as normal, without including an SQL server.
2. Go to your Azure portal and navigate to the "SQL Databases" tab.
3. Create a new database using your existing server, or just make a new database server if you don't have one yet.
4. When it's done (it may take a second for it to show up in the list), click on the new database and it's settings will appear. You want to go to the "Show Database Connection Strings" option.
5. Save the ADO.NET connection string!
6. Go back to your project in Visual Studio and navigate to the Web.config file.
7. In the "connectionStrings" header, find your database context. It should have a name formatted like YOURDATABASENAMEContext, or something similar. It'll probably be the second entry there. Replace (save a copy first, see note below for why) the inside of the "connectionString" with the ADO.NET connection string of the database you just created.
8. Publish and it should work!
NOTE: This workaround, if followed literally, means the program won't function locally anymore (e.g. starting the app rather than publishing it) since it will be looking for that database in the connection strings. You could return it to it's original state for testing, and then use the azure connection string when publishing, although I'm sure there's a more elegant way to do it.
Related
Just created a simple ASP.NET MvC project, to list blood pressure measurements. I opted to use SQLite as a database as it is (supposedly) embedded into the project, therefore eliminating the need for an external database. Which is expensive, and the reason why I chose to go with SQLite. That way I would only need to host the web app, which is free, if I chose the free tier, F1.
Publishing through VS2022 is successful, and the app shows correctly, except it shows none of the measurements. Which renders the app ((no) pun intended) useless, at least as a cloud app. I have done some research, and changed the publishingsettings a couple of times, but this is how they look right now.
Configuration: Release
Target Framework: net6.0
Deployment Mode: Self-contained
Target Runtime: win-x86
File Publish Options: None of the options chosen
Databases: Default Connection - Use this connection string at runtime:
=> Data source=bloodpressuremeasurements.db
Entity Framework Migrations: BloodPressureContext (name of the DbContext)
- Apply this migration on publish: NOT chosen, since it gave me an exception and publish failed
Site Extension Options: Install ASP.NET Core Logging Integration Site Extension
- NOT chosen
I also tried changing the option for the db file to Copy To Output Directory: Copy always.
That didn't change a thing. What am I missing?
The website works now as intended, with all the data shown. It looks like the problem stems from scaffolding read and write methods, which made Visual Studio 2022 pull in EntityFrameworkCore.SqlServer. Which is not what I wanted, since I'm using SQLite.
That in turn created some service dependencies under Connected Services, one of them being SQL Server something. It also appeared under the Publish menu, and seems to have caused the compilator to view the connection string as an SQL Server database connection.
I created a new app, and copied the code from the first one. I was careful not to scaffold, as I only need a Get method, to show all measurements. I need none of the other methods in CRUD, neither Post, Delete, nor Update. I will add new measurements by running the app again locally, and read the measurements from a CSV file (did that in the beginning). Then I will publish the app anew, with the updated SQLite database.
I have Created a cluster in Azure http://******.######.cloudapp.azure.com:19080
but don't know how to deploy my service fabric project on to it.
Link to application manifest
ApplicationManifest.xml
It's pretty well documented, unless you are getting specific errors, which you then will need to reference to get some worthwhile help
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-publish-app-remote-cluster
Your first option is to use the powershell commands. You can also right-click your application in visual studio and select "Publish". Make sure you are using the correct publish profile.
Within Visual Studio, navigate to your Publish Profiles folder under the application and copy/paste the existing cloud.xml file and then rename appropriately. Ensure that you use the correct public facing I.P for your cluster, which will most likely be the load balancer.
The line should look like the following.
<ClusterConnectionParameters ConnectionEndpoint="<YOUR IP>:19000" />
Example:
<ClusterConnectionParameters ConnectionEndpoint="151.41.35.35:19000" />
However, if the cluster is secured you may need additional information. These options are shown within the commented Cluster Connection Parameters of the cloud.xml file.
Right click on the application, select publish and ensure the new publish profile is selected. Visual studio will attempt to validate the connection. Try to publish and keep an eye on the output window for insight in to the process.
I'm using Entity Framework with a code first model; I've got my InitialCreate migration setup and working locally, I can run code against my database context, and everything works.
But when I deploy my project to Azure, I just get a connection string error ("Format of the initialization string does not conform to specification starting at index 0.").
I can't seem to find where in the Publish dialog are the options to create the Azure database. -- Do I have to create the database separately and hook them up manually? -- If so, what exact process should I follow. Does the database need to have contents?
I thought Microsoft was making a big deal that this could all be done in a single deploy step, but that doesn't seem to be the case from my current experience.
When you publish your project in the publish dialog, there is an option for the code first migration in the Settings tab, it will automatically show your data context and it will give you the option to set the remote connection string, and this will add a section in web.config to specify the data context and the Migration class to run during the migration process.
It will also allow you to set if you want to run the code first Migration or not.
You can also take a backup from the dev and clear the data then upload it to Azure SQL DB, this way the code first data context will check at first connection and it will find the code an database the same
I have a build in Team Services (was Visual Studio Online), with one MSBuild step that is configured to build and deploy a DB project, using a publish profile. I can't seem to succeed in authenticating it. When I queued the Team Services build definition, I am able to build the DB Project and produce the .dacpac. However, come publish time and this error comes:
C:\a\1\s\Source\ShopDatabase\bin\Output\MyDatabase.publish.sql(0,0): Error Deploy72002: Unable to connect to master or target server 'mydb'. You must have a user with the same password in master or target server 'mydb'.
We're certain the user exists in the mydb and the master db in Azure.
Target: Azure SQL Database
DB project Target Platform: Microsoft Azure SQL Database
When I run the publish profile directly from Visual Studio, it works. But in Team Services build definition, it doesn't. I tried these as MSbuild arguments:
/t:Build;Publish /p:SqlPublishProfilePath="myproject.Dev.publish.xml" /p:Password="mypassword"
and this:
/t:Build;Publish /p:SqlPublishProfilePath="myproject.Dev.publish.xml" /p:TargetConnectionString="Data Source=myproject.database.windows.net;Persist Security Info=True;User ID=myuser;Password=mypassword;" /p:VisualStudioVersion=14.0 /p:Username="myuser" /p:Password="mypassword"
and this:
/t:Build;Publish /p:SqlPublishProfilePath="myproject.Dev.publish.xml" /p:TargetConnectionString="Data Source=myproject.database.windows.net;Persist Security Info=True;User ID=myuser;Password=mypassword;" /p:VisualStudioVersion=14.0 /p:TargetUserName="myuser" /p:TargetPassword="mypassword"
But won't work. Please help me T_T been searching the net for 6 hours already
This is a poor error message that likely disguises the real issue: you need to open up your firewall for deployment to Azure SQL DB. It's working from Visual Studio because you have your IP range enabled. The steps in this guide to building & deploying from VSO, specifically the post on deploying from VSO here, should help. it specifically covers how to open up the firewall as part of deployment.
An obvious answer (sometimes in hindsight!) but for future googlers the error You must have a user with the same password in master or target server
also happens if you are pointing your deploy to an instance that doesn't exist.
ie: Server was not found.
Fwiw, was generating a script from visual studio. Running as admin made it stop being a douche about this. What a waste of my life just now...
We recently had this issue and we resolved it by removing the #server-name from the end of the Server Admin Login value in the SQL DB Details section of the SQL Deploy VSTS Task. Some guides online say you need this but it appears something changed recently and it is no longer required.
I created a cloud service and tested it successfully locally. I added service configurations for stage and production. Here is a snippet of my staging-configuration:
and here my configuration-settings:
Then when I publish I set up the deployment as follows:
All this worked like 2 weeks ago. But now he deploys in VS and when I look into Azure Service Configure area it looks like this:
I played a little bit with the "Update development ..."-checkbox on the second screen but the result is the same.
So it ignores all the settings I made and just won't tranistion my configuration to the ine I named "CloudStage". My current Web PI tells me that I use Windows Azure SDK for .NET (VS 2013) 2.3. I don't get the point.
Edit
Some more things I observed:
No WADLogsTable and WADWindowsEventLogsTable is generated automatically in the staging storage.
I deactivated Remote Desktop because it was one of the changes I made to monitor the event log (which wasn't useful here)
I manually changed the connection strings in Azure Portal but it seems as if the worker is totally unaware of the storage (rebooted it with no success).
Edit
I recognized another thing. Here you can see a running deployment of my service:
See the warning-mark on the left? If I go to my Error list this is shown:
This warning is senseless since it tells me that I did everything the right way. My *.Local.csfg-files are pointing to the local storage. So?!?
This seems weird. Please check the in your ServiceConfiguration.CloudStage.cscfg to verify the expected values.
Have you tried updating any other property like Enabling Remote desktop? Does that get updated on your deployment? You should select the "Deployment Update" check box in the publish dialog. Now, when deploying to an existing Cloud Service, it should ask you if you want to replace it.
If you get the Object reference error every time you right click on project, there might be some issue with the Azure SDK set up.
I'm a little bit further now. What I did was:
Deleted all Services in Azure.
Deleted all Storage Accounts in Azure
Removed my Service-Project completely from solution (not the library containing the worker-logic).
Re-added storage-accounts in Azure.
Re-added services in Azure.
Re-added a project in the solution and added the worker-logic inside it.
Builded up all the publishing-stuff again.
Published it.
The first publish ended like the one described in my question. After I checked the "Update development..."-option in properties of my worker it finally took my transitions into the stage!
Now I recognized, that WADLogsTable was still empty. I hit the instance right in server-explorer and choosse "Update diagnostic settings...". There was an option "Transfer period" suddenly set to "None". This explained to me, why my table was empty and after I set it back to "1" my table is filling again!
Another funny thing beside: When I right-click my Cloud-project in the solution I get "Object reference not set to an instance...". When I just click it left and choose Build->Publish it works.
I just hope that I can help somebody with this. Lets see if it's stable now.
Edit: Yesterday it worked - today is still the same issue :-(.
When you get "Object reference not set to an instance.." for a CloudService project you usually have some kind of mismatch. It could be that a setting in the ServiceConfiguration is not defined in the ServiceDefinition. It could also be that there is a publish profile defined in the .ccproj file for the CloudService that doesn't exist. This might also be what is causing your problems with the different configurations.
So it turns out that the problem is completely on client-side. My Visual Studio (now with SDK 2.4) is doing something wrong. I set up a fresh installation with all the stuff needed :-( and there it works perfect. I'll try to determine if one of my extensions is causing the strange "Object reference not set..."-bug.
Repair-Installation of VS does not solve the problem btw.