I am having a problem with Web Deploy packages recognizing SQL. I am using Visual Studio 2015, SQL Server 2014, SSDT Database Project. The workflow is, create a MVC project, create a Database project, and use the Web Deploy Package to run SQL queries on the DB project. I plan to Publish the MVC project into a web deploy package and add queries to the deployment as part of the package. (I am not trying DACPACs at the moment because I ran into issues where they were not including pre and post deployment scripts in them when using Web Deploy Tool).
The problem happens when publishing a web deploy package using the connection string below.
<connectionStrings configSource="connectionsettings.config">
That in the web.config prevents web deploy from detecting a database to add to the web package for web deploy packaging.
deloy package missing database
Whenever I change to a normal connection string, even something as simple as this:
<connectionStrings>
<add name="Default" connectionString="" providerName="System.Data.SqlClient" />
Then web deployment package works and you get the proper UI.
deloy package working
Anyone know how to get the database to show up using a configsource in the web.config connectionstrings? As an alternative, I was looking into getting parameters.xml to replace the blank connection string to include the configSource above, but have had no luck.
The idea was to remove the Default connection and replace it with the config source. Removing the default connection works but the configSource does not.
<parameter name="RemoveConnectionString" defaultValue="">
<parameterValidation kind="AllowEmpty" />
<parameterEntry kind="XmlFile"
scope="Web\.config$"
match="//configuration/connectionStrings/add[#name='Default']" />
</parameter>
<parameter name="AddConfigSource" defaultValue="connectionsettings.config">
<parameterEntry kind="XmlFile"
scope="\\web.config$"
match="/configuration/connectionStrings/#configSource" />
</parameter>
Web Deploy Package seems undeveloped for SQL, but is there a fix for my issue or a better way to do an all-in-one deploy for IIS & SQL?
Use WebDeploy Parameterization to manually create parameters for the separate config file.
Skip down to "Step 3 - Create a parameter file" in the following link:
http://www.iis.net/learn/publish/using-web-deploy/web-deploy-parameterization
This may also be helpful:
http://www.dotnetcatch.com/2014/09/08/parameterizationpreview-visual-studio-extension/
Related
I´m trying to configure the application pool to .NET v4.5 Classic from the default DefaultAppPool for a web service deployed in IIS 10, developed with Visual Studio 2019.
These are my steps:
I created a file called parameters.xml in the root with the following content:
<parameters>
<parameter name="appPool" defaultValue="SealSignAppPool">
<parameterEntry kind="DeploymentObjectAttribute" scope="application" match="applicationPool/#applicationPool" />
</parameter>
</parameters>
Create the package from right click on the project -> publish:
The package is created and I can view the parameter correctly configured inside parameters.xml in the deploy zip:
After deploy, the Application Pool remains the default.
NOTE: If I use Import Application Wizard with the zip deploy, I can see the parameter, but in the import log says it can´t be applied to any site...
======================================================================
== UPDATE 1 ==
I´ve added in Web Deploy Package.pubxml the missing properties:
<IncludeIisSettings>true</IncludeIisSettings>
<IncludeAppPool>true</IncludeAppPool>
With only IncludeAppPool nothing changes.
With IncludeIisSettings added I have a exception and the package publish fails with "EscapeTextForRegularExpressions" task was not given a value for the required parameter "Text"
I searched and the recomendations are set IncludeIisSettings to false... :(
Any idea what I missing??
Thank you.
I have .NET Framework 4.7.2 project that uses for a azure app service that uses for API calls.
I want to use a different appsettings.json for each environment, I have multiple environments (production, pre-production and more...)
I saw this docs: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-3.1
But I didn't find something similar that works with .NET Framework.
How should I do it?
I don't think there's a simple/supported way of getting the settings filename override functionality that NET core has for .Net Framework because it doesn't have or use environment variables and projects/executables in the same way.
But there is a library called Slow Cheetah that seems to do this, which allows you to automatically transform your app.config (or any file) when you press F5 in Visual Studio
I ended up using a single App.config file with different keys - see below.
From here, you'll just need to work out your own trigger for determining your Dev/Prod etc environment - probably a build step.
(In my case, I had a ClickOnce app that was either published/prod or not/dev - so this part was easy)
<connectionStrings>
<add name="Dev"
connectionString="..." />
<add name="Prod"
connectionString="..." />
</connectionStrings>
We have a continuous delivery process created using Jenkins, MSBuild, and Web Deploy. Things work beautifully when deploying to our development server, however, when I try to deploy a web deploy package using the *.deploy.cmd file on two newly configured servers the web.config changes defined in the parameters.xml file are not being applied. The rest of the deployment works great but I am seeing a message like this for every parameter that needs to change:
Verbose: Parameter entry 'config/1' could not be applied to '<path>\Package\PackageTmp\Web.config'. Deployment will continue with the original data. Details:
Cannot set a value on node type 'Element'.
Since the transforms for the exact same package work on deployments to one server and not to the new servers, this seems like a server configuration issue but I've gone through and checked everything against Microsoft's Web Deploy install instructions and it all looks fine. I wasn't the person who originally set up Web Deploy on the working folder so I don't know what they might have done differently. I suspect this is related to permissions but the few places I can think to check were the same on both servers.
I found other questions with this error message where it was an issue with the XPath in their parameters.xml file. I don't think this is my problem because I can deploy successfully to one of my servers but here's an example from my paramters.xml and SetParams.xml files for good measure:
parameters.xml
<parameter name="config">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="//configuration/appSettings/add[#key='config']" />
</parameter>
*.SetParameters.xml
<parameters>
<setParameter name="config" value="<add key="config" value="testing" />" />
</parameters>
Does anyone know how to fix this or what kind of additional permissions I will need on my new servers?
In retrospect this is embarrassingly obvious but it turns out that our issue was that the server support team had installed the wrong version of Web Deploy. We needed 3.5 or higher and they installed 2.10. Updating Web Deploy on the new servers resolved the issue.
I have a site that's running off windows azure and I have hooked up the database via a linked resource and it looks like the site should be using the database. I've also included the proper connection string in my web.config file.
When I run the website locally and use the azure database's connection string for my default connection, everything works and I've seen that updating data from my local machine is reflected in the remote database.
Whenever I try to access any page that makes database hits (ie, logging in or looking at the basic index (from scaffolded out views)), I get a 500 error. I tried turning on custom errors but the 500 error is all I get. I tried to debug it from my local machine but that didn't help at all since everything worked properly when running the site locally and connecting with the azure database.
I have also pulled down the web.config files and the web.configs on both sides are identical.
I figure that this has to do with a configuration issue, but I'm not sure what.
Is there maybe something I'd have to do with asp.net mvc 5 to make it work with windows azure? It looks like the .net framework is properly set on azure to .net 4.5. I'm guessing it has something to do with the fact that Azure just doesn't know it should be using the database supplied in the web.config.
Here are the web.config connection strings:
<add name="DefaultConnection" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnectionDeploy" connectionString="Data Source=####.database.windows.net;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnection_DatabasePublish" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
Windows Azure makes use of transforms to manage connection strings. The connection strings are merged in at runtime, and can be controlled from the configure tab on the Web Site management page. whenever you set up an Azure Database as a linked resource, it automatically configures the Azure Database server with firewall rules to allow connection from the web server, and adds a connection string. By using this connection string, naming it the same as the string used in development, it is not necessary to modify any code prior to deployment. If you don't set the Azure Database up as a linked resource, it is necessary to modify the firewall rules by hand, which doesn't play nicely with the scalability of Azure Websites, so it's not recommended.
As per Andrew-counts' suggestion, I went and checked out my EF migrations (after pulling down the Azure web.config file using the "Replace web.config from server" option so that I had the exact copy that the server is using. I then enabled custom errors. It turns out that the pages were failing to load because of an error that stated that the table dbo.AspNetRoles already exists.
It appeared as though it was trying to run the EF migrations despite the fact that the tables already existed. To remedy this, I decided to go and wipe out my current database (I had just setup the database today so no harm doing that) and then, from the package console in visual studio, ran the Update-Database script before deploying anything to the server. When I did that, it correctly added the records inside of the dbo.__MigrationHistory table. I then checked in my changes so that the visualstudio.com build I have connected to my solution would build and deploy to Azure. The problem persisted, but what I realized was that I need to disable the automatic build + deploy that I was using and instead use the right click + publish, since doing it from the visual studio build wasn't connecting to the azure database properly (it wasn't transforming the web.config). When I used the publish from within visual studio, the site worked like a charm.
Thank you for all your help
I am looking for a way to deploy to multiple different environments.
ie, dev, uat, prod1, and prod2 servers
I am under the impression msdeploy could work for this. Currently we have something that deploys using a command like
"C:\Program Files\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:contentPath="D:\sourcepath" -dest:contentPath="D:\destpath", computerName=PRODSERVER1
"C:\Program Files\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:contentPath="D:\sourcepath" -dest:contentPath="D:\destpath", computerName=PRODSERVER2
This would work, but in the application I'm developing that needs deploying has a database connection involved, which needs to be changed per environment.
<connectionStrings>
<add name="DEVServer" connectionString="Data Source=DEVServer\SQLinstance;Initial Catalog=DBNAME;User ID=sqluser;Password=sqlpassword" providerName="System.Data.SqlClient" />
</connectionStrings>
Also, since this is a WCF service I have an Identity for the endpoint that would need to be changed per environment as well
<identity>
<dns value="DEVServer" />
</identity>
Is there a way to parameterize this? Should I set up multiple web.config files? What is the easiest route to go about this?
Assuming you are using Visual Studio 2010 or 2012, you can set up a publish profile for each environment and put the database connection string in that, set up a Web.config transform for each publish profile to make the endpoint changes, and you can deploy using MSBuild from the command line instead of msdeploy directly.
For details on how to set up publish profiles, see http://msdn.microsoft.com/en-us/library/dd465337.aspx
For Web.config transform examples, see http://www.asp.net/web-forms/tutorials/deployment/deployment-to-a-hosting-provider/deployment-to-a-hosting-provider-web-config-file-transformations-3-of-12
On publishing from the command line, the format would be like the following for publishing a solution:
msbuild path\to\solution.sln /p:DeployOnBuild=true /p:PublishProfile=[nameofprofile] /p:Password=[password]
To publish a project rather than a solution, specify the .csproj/.vbproj file and add /p:VisualStudioVersion=11.0 for VS 2012 (10.0 for VS 2010).