Windows service / Debug bin folder?

Legacy Execution
1

Hello,

I’ve started using Team City + Octopus since last week, and successfully deployed 2 Web APIs.
However, I need to deploy a windows service and even though it succeeds, it doesn’t do what it should.

Pretty sure I’m missing something?

Nowadays, we deploy this windows service manually by following these steps:

  1. Clean Build “Release” the project in Visual Studio 2017
  2. Stop windows service on the server
  3. Copy the contents of bin/Release folder to our server’s folder
  4. Start windows service on the server

On deploying the windows service using TC + Octopus we see that it pushes the contents of the package correctly, but it pushes a bin/Debug folder to the “Custom install directory” though.

  • Why not bin/Release folder? If so, I would move its contents to the root of the “Custom install directory” and that would do the trick.
  • How could I set up the project to copy the contents of bin/Release folder to the “Custom install directory”?

Regards,
Rogelio

2

One more thing:

Substitute variables in files is not working:
"Parsing file ‘C:\Octopus\Applications\IAR-UAT\ERRSSmtpProcessor.IarWeb\134_4\bin\Debug\ERRSSmtpProcessor.exe.config’ with Octostache returned the following error: `The following tokens were unable to be evaluated: ‘#{FileAppenderPath}’, ‘#{ErrorSmtpAppenderTo}’, ‘#{ErrorSmtpAppenderFrom}’, ‘#{ErrorSmtpAppenderServerName}’, ‘#{FatalSmtpAppenderTo}’, ‘#{FatalSmtpAppenderFrom}’, ‘#{FatalSmtpAppenderServerName}’, ‘#{RollingLogFileAppenderPath}’

All of them DO exist though:

I’ll send the log through to support at octopus dot com so that you can take a look.
Please advise, why are they not being evaluated/substituted?

Thanks

3

Hi Rogelio,

Thanks for getting in touch! When Octopus deploys your package, it deploys the entirety of the package “as is” and keeps any folder hierarchy that was in the NuGet Package. This means that any bin/Debug folder you have in your package will be deployed. So a couple of options here would be to have your debug files built to the root(or wherever needed), or you could copy them via Custom Script.

Also, if you would like a bit of further reading on Windows Services (you may have already seen it), we have some good documentation there.

As for your variables not transforming, by the looks of it, you are declaring them in your project with the #{} encapsulation. This encapsulation is automatically handled by Octopus and not required when declaring variables in the editor. If you remove the encapsulation from the variables in the project, the transformations should work as expected. If they do not, please attach another deployment log. :slight_smile:

Let me know how you go here, or if if have not answered your questions

Best regards,
Daniel

4

Hi Daniel,

"and keeps any folder hierarchy that was in the NuGet Package"
Correct, but I’m using Octopack so that it creates packages automatically. Where can I switch it to Release Build?

"or you could copy them via Custom Script."
Already created it. Need to have the Release build instead though.

"not required when declaring variables in the editor"
Thanks, it worked!

5

Hi Rogelio,

Thanks for getting back. I’m glad to hear that the variables are working for you now. I have some information here that could help you with the packaging hierarchy. In our Documentation, we have the following section What is packaged?

The following is a snippet from the above page:
If you are packaging a .NET application, OctoPack will automatically package all of the files in the build output directory for the project. In most cases this will be the bin, bin\Debug or bin\Release folder, depending on the build configuration and whether you have changed the build output directory for your project in Visual Studio.

Let me know if the above documentation helps you organize your folder structure how you need it, or if you need any further help here. :slight_smile:

Best regards,
Daniel

6

I’ve managed to get the bin/Release folder from Team City command line option
working now

thanks

7

Hi Rogelio,

Great! Feel free to get back in touch at any time if you have any further questions / issues.

Best regards,
Daniel