Is all we need to copy across is .exe and .exe.config ?
or do we need to copy .dll's and .xml as well?
If there is any 3rd party dll (or any dll which is not a part of the .NET Framework) being used by your service then you will need to copy it along with your executable. Hope you also know that .NET framework must be installed in the target machine where you are planning to deploy your service.
Related
I come from the desktop application world (WPF, WinForms), where the convention is to deploy your exe to \Program Files[ (x86)]\CompanyName\AppName\ directory, and store all the data in \Program Data\CompanyName\AppName\ directory.
What's the corresponding convention for deploying Asp.NET Core web services on a desktop (not a server) PC? Program Files directory doesn't seem like a good idea, because it requires admin credentials for writing, a problem you hit the moment you try to publish the app. On the other hand, while Program Data doesn't have the permission problem, it just doesn't feel right, given there is no corresponding Program Files location.
I've also seen C:\intepub\wwwroot\web-service-name used, when IIS was involved. Is that the way to go? I'm guessing it makes sense when running Asp.Net Core app in Kestrel behind IIS as reverse proxy, but what if I were to host my app inside a Windows Service instead?
There is a lot of enduser as well as enterprise apps deployed as windows services with embedded web applications (using Apache, tomcat..etc) Under Program Files, Ex: HPE server admin/config tools.
So for Kestrel APP, I would deploy bin in Program Files and write logs,DB,etc under Program Data. it will works without permission issues since dotnet binary has the needed perms.
All the deployments in my work place are manual. I have been looking at ways to automate all of this using MSBUILD and MS Web Deploy. What I have managed to get working is as follows:
build/compile solutions
run database migrations
deploy directly to website using ms web deploy
All from one MSBUILD script.
This differs slightly from the manual process, as when a new version of a website is deployed manually, it is put into a new folder that is datetime stamped. And then IIS is pointed to the new folder.
My question is, how would I do these last 2 actions? i.e. write to a specific folder that sits a level higher up than the folder the current website points to, and then repoint to the new folder IIS.
Web Deploy does not support this functionality directly. Thankfully it does provide the runCommand provider, which is what you'll end up using.
%windir%\system32\inetsrv\appcmd.exe is the utility you'll use to swap site directories. An example of usage can be found here: How do I change the physical path of web site in IIS7 with APPCMD?
Create a script that calls appcmd. This script will always sit on your destination server. You can either decide to include it as a part of your site deployment, or move it along into the new directory from the old one. The "web deploy user" on the destination machine needs to have the appropriate credentials and access to create directories.
In your MSBUILD script, prior to deployment, call the script on the destination server. E.g.
msdeploy.exe -verb:sync -source:runcommand="C:\path\to\wwwroot\bin\script.bat"
-dest:auto,wmsvc=https://contoso.com:8172/msdeploy.axd,username=%username%,password=%password%
Then deploy as usual
NOTE:
Try to avoid this way of deploying entirely. If you're looking to snapshot your site, consider deploying to a package (zip), and then deploying that package to your destination server. Rollbacks should be handled by deploying an older package, not by repointing to an older directory.
I have several ASP.NET application running under a common IIS Site and would like to use a NuGet package to transform their config while copying versioned JavaScript file to the IIS Site's Root application Content folder.
Can NuGet be used like this? I.e. can it be determine during package installation/updating which IIS Sites root application an ASP.NET project is being run under (using the preinit powershell script for example).
The tool you are looking for is Octopus Deploy It install nuget packages on IIS, as windows service, etc. Moreover it gives raeally nice GUI for management.
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
I need to make deployment our ActiveX control(two .dll files) through Web with using ActiveX. I saw that deployment .NET application with using ClickOnce is very easy, just need in VS click Build->Publish, but I can't find how I can make it with ActiveX.
Thanks, Roman
That's not possible, the point of ClickOnce is to not alter the configuration of the target machine in any way. Quite the opposite of what is required to get an ActiveX component functioning, it has to be registered and that requires altering the registry with an admin account.
I'm trying to deploy some sort of framework and therefore need to register some assemblies in the GAC.
The interesting part is:
These GAC assemblies should only be used by the framework developer, the client apps should not use these GAC assemblies but the ones in their local directories (the GAC assemblies could be of a different version, most likely higher).
I've already found and tried the app.config setting but it seems to be ignored by the client app (latest .NET runtime installed is 3.5).
Because you will be loading two different versions of a given dll in the memory you need to isolate them. common methods are;
Creating an AppDomain. You create two dll's. The first dll creates a new AppDomain from your code and then loads the second dll which is linked to those dependencies.
Use a service process. You create one dll and a service application. The dll starts the service application in a new process and connects using for e.g. remoting. The service application is linked to the components you need to bind to.