In TeamCity I have created build step that is running MSBuild with target Package(not my script just MSBuild runner from TC pointing to csproj), then this package is deployed through web deploy to iis.
Problem is that deployment is creating new application under Default Web Site and I would like to deploy it to one already existing.
So I added parameter to build DeployIISAppPath=Default Web Site\ MySite and I have checked that in generated SetParameters file it actually is Default Web Site\ MySite but still this value is ignored and app is deployed to XXX_deploy virtual directory created by deploy.
Any idea why?
Related
I have the following code:
var config = new ConfigurationBuilder();
config
.SetBasePath(Directory.GetCurrentDirectory())
.AddEnvironmentVariables()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{environment}.json", true);
Which works fine in development environment and production too. However if I place this:
Raise<FileNotFoundException>.If(File.Exists(Path.Combine(Directory.GetCurrentDirectory(), "appsettings.json")),
$"Could not find the settings file");
It raises exception during debug sessions and release sessions (basically when the app is not published and executed from Visual Studio) that file could not be found which is kind of correct because VS2017 does not copy settings file to the debug folder and instead keep them in the source folder. So my question is,
how does the dotnet core resolves the configuration path for aspnet core?
I think you're getting confused on things here. The configuration is pulled by default from the entry point directory. Inside Visual Studio or when running dotnet run from the command-line within your project root, everything works fine. Also, when you publish, the published directory will contain the configuration files alongside the entrypoint DLL, so this will work fine as well.
What you seem to be talking about is running from the bin directory, which is not a supported thing. The bin directory is effectively a cache. It's not a published version of your application, and thus cannot be run as if it is.
I created a helloworld eclipse RAP project and run it eclipse itself.It is working fine.
After that I exported the RAP project to war file by using the eclipse war product configuration.
It created the war file.I deployed the war file in tomcat. After that when I try to access
the war deployed helloworld application, I am getting status 404 error.
http://127.0.0.1:8080/helloworld
I searched in internet and checked for troubleshooting and they mentioned to check in web.xml
all the entries are available or not. I confirmed it is available. Also I checked application structure.
It is fine as it is suggested. Could any one help me how to access the deployed application in tomcat?
Or is there any other server I can use in order to make it work quickly?
I suppose that the war file is named helloworld.war and http://127.0.0.1:8080/helloworld is the URL of your application.
If your entrypoint is not registered at the root path, you have to add the entrypoint name to the URL, e.g. http://127.0.0.1:8080/helloworld/entrypoint.
Alternatively, you can register the application at the root path in your ApplicationConfiguration:
application.addEntryPoint("/", YourEntryPoint.class, properties);
Then you should be able to access it at http://127.0.0.1:8080/helloworld.
Update:
If you use extension points, configure the path in your entrypoint extension, for example:
<extension
point="org.eclipse.rap.ui.entrypoint">
<entrypoint
class="example.MyEntrypoint"
path="/" />
</extension>
I am trying to setup a CI process with Team Build and VS2012. I've setup the web server to accept web deployment. I've installed Web Deploy 3.0, IIS Management Services and have configured the permissions to the website dir.
I have a msbuild project that compiles, packages and then deploys the site using MSDeploy but I'm coming across a issue that seems to be happening to many but I haven't been able to find a clear answer.
The problem stems from needing to pass in the site name to MSDeploy so that the user the build server runs under can publish. Like so:
https://computername:8172/msdeploy.axd?site={websitenameonly}
I've tried various ways to include this in the MSBuild file but they all end in failure. The '=' seems to break the string and cause the {websitenameonly} to be considered as another parameter.
Has anyone successfully been able to pass in the site name via MSBuild?
The MSBuild scripts will append ?site for you, so there's no need to do it yourself.
Make sure you've set the following in your pubxml:
MSDeployPublishMethod is WMSVC
MsDeployServiceUrl is in the format https://computername:8172/msdeploy.axd
DeployIisAppPath is set to your IIS site name
You haven't set NormalizePublishSettings to false (I doubt you have, but worth checking)
I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.
When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.
What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?
(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)
We do our WebDeploys with a TeamCity MSBuild step configured as follows:
Build File Path: Server.csproj
Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site%
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.
I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.
To deploy the package.zip file on the command line:
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.
Use TeamCity build step and the command line runner.
Update:
If you want an example of how to build the ZIP package using MSBuild, try something like this:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"
This should work the same on your local PC as well as on the CI server.
Here are the config settings that finally worked for me:
/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True
/P:CreatePackageOnPublish=True
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True
I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile
Basics were:
Install the Azure SDK 1.8 on the build server
Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile
Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.
This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.
I'm using IIS6, Web Deploy Agent Service, and MSBuild's MSDeploy hooks to deploy. It deploys right now with this set of arguments to MSBuild:
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployServiceURL=example.com
/p:DeployIISAppPath=example.com/DeploySiteName
/p:CreatePackageOnPublish=True
/p:MsDeployPublishMethod=RemoteAgent
/p:AllowUntrustedCertificated=True
/p:UserName=login
/p:Password=pw
With that, it will deploy to C:\Inetpub\wwwroot\wss\VirtualDirectories\example.com80, where the Website files are located.
Unfortunately, I need it to deploy to D:\Webs, mostly for space reasons.
I'm trying to figure out what switch, if any, will allow me to deploy to an alternate physical path and map the virtual directory.
I tried reverse-engineering C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets like another SO post suggested, but I failed... I tried using combinations of these parameters and they had no visible effect:
/p:DeployIisAppPhysicalPath=D:\Webs
/p:RemoteSitePhysicalPath=D:\Webs
Any suggestions?
If you create a virtual folder in IIS6 to point to a different physical location to start with, then pass in the path and parameters like you listed above MSDeploy will write to the correct physical location.