I published my project, which uses Application Insights, on an IIS server. The files I published are: all DLL from Application Insights, the script tag for collects http requests from the view that i want to track, and the applicationInsights.config with the intrssumentation key in it.
The issue is that not collect SQL dependencies. But the interesting thing is that when I run the project in Visual Studio it collects all the dependencies including the SQL dependencies.
In this case, what could be the problem? a configuration issue on the server? something missing from publish to server?
If you're seeing them collected locally while debugging, but not when deployed, then chances are you have a different version of .net or the AI sdks installed in the 2 places, or you're missing a required library when you deploy? make sure your deployed items are the same as your local dependencies?
see: https://learn.microsoft.com/en-us/azure/azure-monitor/app/auto-collect-dependencies
for a bunch of the details about versions and packages, etc.
Related
I installed the Application Insight SDK from nugget packages and when I run the code I am able to log the telemetry data to cloud. Now I want to move these bits to my TEST server.Can I copy the bits directly to TEST server. after doing this, does the application logs the data to Azure?
I am using ASP.Net Application.I created Application Insight Resource in the cloud with the application type as ASP.NET.
The Application Insights SDK libraries should be deployable using XCOPY (i.e. just copy everything along with your application) without problems. Make sure to include your ApplicationInsights.config file and any changes to the Web.Config file as well.
However, remember that if you want to capture dependency calls in an IIS application, you will need to also install Status Monitor on the Test server as well.
What are the options for deploying a web-application that is built daily using Visual Studio Online (and hosted controller) and its new build definitions to an on-premises IIS behind a firewall?
If opening up the firewall, would it be possible to add some kind of WebDeploy-build step to the Visual Studio Online build? Haven't seen any WebDeploy build steps for now though...
...or could we write a PowerShell script running daily on the IIS-server that fetches the output of the daily build from Visual Studio Online? If that's possible, how can those files be accessed?
...or could something like OctopusDeploy help out here?
would like to refrain from having to set up an on-premises build controller.
VSO Agents are lightweight and easy to setup if you have a server available. Octopus Deploy integrates nicely most on premise scenarios.
That said, if you still want to keep hosted builds, Octopus would still work.
Create a VSO build definition and include OctoPack.
Pick a hosted Nuget Server, presumably with a private repo subscription. A couple of options are MyGet and Artifactory.
In "MSBuild Arguements" include the parameters.
/p:RunOctoPack=true
/p:OctoPackPublishPackageToHttp=http://nugetrepoofyourchoice.com/nuget/packages
/p:OctoPackPublishApiKey=$(NugetAPI)
/p:OctoPackPackageVersion=$(Build.BuildNumber)
"NugetAPI" is actually a user defined variable (name of your choice) that references a Secret build variable. You will get this API Key from your Nuget Repo vendor.
On premise, in your Octopus installation, you would define your hosted Nuget feed as an external feed.
In your deployment project, it would pull the Nuget package from your hosted repo.
VSO pushes to hosted Nuget feed and Octopus pulls from the hosted Nuget feed.
Octopus deploy would work for this in a couple of ways.
1) Install a tentacle on the IIS server (either polling or listening will work depending on where you install octopus manager)
or
2) Install the main octopus deploy on a machine that has WebDeploy access to your IIS server, and use the custom library MS Deploy script
Getting the package to the main octopus deploy machine could be a bit tricky. Easiest way would be setting up a MyGet server and have the octopus server check it periodically, that way you don't need to open up firewalls to the public.
These feature are coming for VSO and were announced at Build. You will be able to deploy on-premises without needing to open a firewall port using agents.
While this is still in the works you can use Release Management for Visual Studio 2015 to pull the bits from VSO and deploy locally.
In my organization the main product is a web application and an associated database. Both the web application and database is source controlled in TFS. We are running this product in various versions across hundres of IIS web site instances. When having that many web site instances on IIS deployment is atm. a problem.
What I want to do is to package my web application together with the output from my database project. I've been looking into creating a Web Deploy Package which makes it easy to deploy a web application remotely, locally or programitically to IIS if i want to.
What I want to achieve is to have one package but I want to know if it's possible to embed a Database project into a Web Deploy Package taking advantages of dacpac incremental database deployment?
If this is not possible is there any good alternatives to Web Deploy Package that suit my needs?
Another method is to create an MSI package to deploy both the Web Deploy Package and also update the DBs. For example, with Advanced Installer you can use the built-in support for Web Deploy Packages.
To perform dacpac incremental database deployment you can call SqlPackage.exe from the same MSI, as a custom action. The linked example shows a simple EXE running, but you can change that to run any desired EXE, passing your required command line parameters.
If you perform frequent upgrades of the websites, or the settings are usually changed after the installation/deployment, then you should take a look at the next thread too, it talks about persisting website installations during upgrades.
I am stuck with a problem that I could use some feedback on to solve it in the best possible way.
The issue revolves around source control -> automated builds -> deployment. Basically ALM (Application Lifecycle Management).
We have a product – an ASP.NET Web application with a MS SQL database. This product is running on hundreds of websites with associated databases across multiple virtual machines in our production environment. At the moment the web applications and database are running on servers with IIS 7 and SQL Database Server 2008 R2. The product itself is source controlled in Team Foundation 2012.
For years the release of new versions of the product has been once or twice a year for years. Now we are going to focus on releasing more frequently and hence we need a strategy for the ALM for the product.
The deployment strategy now:
In the development period between the releases, the SQL update scripts has been created manually – each time a database change was made a script was updated. When the application is ready to be deployed it gets compiled on a developer machine. The database with all the changes used would be backed up into a .BAK file. The web application, the .BAK file and the update SQL script would be packaged (.zip) and uploaded to the production environment ready for deployment.
Update existing running products:
Copy/paste the web application in the target website physical folder.
Update the web.config file – connectionstring and application
variables. Run the update script via SQL Management Studio
This would be done for each and every customer – hundreds of times.
This is a very tedious and error prone task and I don’t like it at all!
What I would like to do instead is;
Source control the database as a Database Project in Team Foundation
Automatically build the web application with Team Foundation 2012
Build Server.
Deploy the output from the Build Server to the multiple websites of
the production environment along with automatically generated SQL
update scripts run against the SQL Server.
I have been googling my ass off - only finding bits and pieces regarding builds, deployment, automatic SQL update script etc.
What I think is partly the right direction is to source control the database and use the TFS Build Server. I am very confused on how to do the deployment itself in an easy and controlled way using the output from the TFS Build server.
Ideally I would want to the TFS Build server to create a package with the latest version of the Web application, the latest version of the database, post deployment script including an auto generated SQL Update script from the previous build to the current build. This could be contained in e.g. a nuget package. Then I would want to be able to create an additional web application which should manage the deployment – target, version, iis website, sql server, web.config connectionstrings etc.
Does anyone have any advice on how to achieve this? How do you do this?
You can use a release management tool to do this, no need to create an additional web application.
One such example is Deployment Manager, from Red Gate. (Disclaimer: I work there.) It has built-in deployment actions for ASP.NET apps and SQL Server databases. The command line tool RgPublish.exe can be used to create a package for the web app as you describe from TFS Build. The same can be done for the database using the sqlCI.exe command line and associated NANT/MSBuild scripts.
The same packages can then be deployed to each of your servers. You may run into scalability issues with 100s of websites though.
The database deployment works by generating the upgrade script automatically, though you can change the behaviour to put the upgrade script in the package, when the package is first built. These are called "dynamic" and "static" upgrade methods respectively.
I am looking for some ideas on how to offer a installation package for my ASP.NET website. Some things I need to be able to do is read/write Registry keys, get the database(s) information and test the connection and I must be able to overwrite the existing website without an uninstall and update the web config on new versions. I do not wish to uninstall the website and re-install it. I would like minimum downtime on upgrades. I think I am going to have to implement a custom solution and if this is true how can i include all the output of my web application into my custom solution?
EDIT: I am not installing this on my own system(s). This is for distribution to other clients who will be installing/upgrading the website. It is important that I be able to upgrade to the latest asp.net website without uninstalling. Ideally it would be overwriting the existing site and updating the web.config file.
Option 1. Create web application installation package
Use Web Setup Project for creating a web application installation package (.msi)
Creating or Adding a Setup Project at MSDN
You can create your installation the way it will offer user an Upgrate option of your application if it's already installed on his or her machine. That's not a problem.
Alternatives to Web Setup Project (all of them can handle upgrade scenarios):
Wise Installation Studio
InstallShield
Nullsoft Scriptable Install System - this one is free and open source
Optoin 2. Deploy web application on the server
You can use NAnt or MSBuild or IIS Web Deployment Tool for these tasks automation.
For example with NAnt of MSBuild you could specify tasks like these:
get project files from source repository
update .config file and maybe some other files if needed
compile you web application
update registry settings on the server
update database schema on the server
synchronize files (x-copy) between you build folder to IIS web folder
Web Deployment Blog
Option 3. Distribute your web applications via Web Plafrom Installer.
http://www.microsoft.com/web/
Have you looked into Web Deployment Projects or the IIS Web Deployment Tool?
I think you can build asp.net application into .msi package and install it. Is that what you are looking for? And then you can build all of your customization into pre-deployment and post-deployment scripts.
I use NAnt and NSIS with some small console apps where they can't easily do some manipulations I require.
Do you tried the new Microsoft Web Platform Installer (new! 2.0 beta)?