We Keep Coding

Debugging Topshelf Service

I am using Topshelf to create a Windows service which uses the chrome Selenium driver to manipulate and parse various webpages.
While the service code runs fine from a normal (NetCore2) console test application, there's a problem when it runs under the Win32 console app that Topshelf requires.
Unfortunately, I haven't been able to figure out how to debug into the underlying service code. The VS2017 debugger appears to be attached to the Topshelf console app, but won't let me step into the underlying service code, which is in a separate NetStandard2 class library. Specifically, when I come to this line in the Topshelf console app:
var scanEntry = _scanner.Run();
where _scanner is an instance of the object that does the actual scanning, I can't step into the code (i.e., F11 just steps over the line).
I tried inserting the following line into the class library scanning code:
System.Diagnostics.Debugger.Launch();
but it doesn't do anything; the code just keeps merrily executing along.
I suspect this is related to the fact that the scanning code is running in a separate process that Topshelf launches. But I haven't been able to figure out how to identify it through Visual Studio's Attach to Process mechanism.
Pointers on how to debug the underlying service code when it's running under Topshelf would be much appreciated.
Additional Info
When I tried stopping on that _scanner.Run() line, and using the context menu to single step into the class library code (rather than using F11), I got prompted to turn off Just My Code, which I did. The VS debugger then tried to step into the class library code, but complained that it couldn't find the library's symbol file (*.pdb).
Which is really weird, because a symbol file with that name exists in the bin folder for the Topshelf console app.
I tried manually opening the pdb file from the bin folder, but got an error message that "A matching symbol file was not found in this folder".
Is this related to trying to debug a NetStandard2 class library from within a plain old Net console app?

Okay, turns out the problem was related to debugging a mixed NetStandard and NetOriginal code base...
NetStandard class libraries, by default, do not generate debug symbol information usable by NetOriginal apps. You have to go into Project Properties -> Build -> Advanced and change the type of debug information being generated from Portable to Full.
Once I made this change I was able to step into the class library code as per usual.
I found this at a matching symbol file was not found in this folder

Web reference not found when distributing application

My question is, when an application uses a web reference is one supposed to hand out something extra along with the .exe file?
I have made an application that uses a web reference for dotMailer API (it's for email campaign management).
The application compiles and runs fine on my PC. But tested it on another machine and kept crashing. After loads of troubleshooting I found this is due to calls using the dotMailer API.
I discovered that Fusion logger is the right tool to show me the reason for failing, downloaded and installed it on the test machine and viewed the logs. Some say the operation was successful while others say it failed even though the assembly download was successful. The test machine has web connectivity. I am just starring at the screen frozen don't know how to tackle this.
Is one supposed to copy something from the Visual Studio project folder over to the test machine for a web reference to work?
I am using Visual Studio 2010

Go to your Project -- > Reference --> Right Click on dotMailer (Your Reference) --> Go to Properties --> Set Copy Local property value as True. Like Below
While distribution of project, we should set the references "Copy local Property as True". Then only the referred Dll's will be copied to publish bin folders.
Reference is here
Related Question / Thread is here

How to enable WCF debugging in the code

I have a self-hosted WCF service. I don't have an app.config file, instead all the configurations are performed at run time in the code. But I cannot figure out how to enable debugging in the code.
UPDATE
I have a VS solution with two projects:
WCF service hosted in a WinForms application
Simple console client consuming the service
I'd like to be able to start the debugging session in Visual Studio, debug the client, set and hit breakpoints in the service application. I was able to do this when I used app.config files, but now I'd like to do the same without them.

Attach the debugger to the process that your wcf service is running in.
If in IIS you will have to attach to the corresponding w3p.exe process.
If in a stand alone app or windows service, attach to the name of your exe.
In VS in debugger option there is sub option "attach to process". You will need to set brak point to the appropriate code and call the service causing that code path to execute.
Can refer this link:
http://msdn.microsoft.com/en-us/library/aa702726.aspx
as well as this one:
http://www.codeproject.com/Articles/17258/Debugging-WCF-Apps
This might be helpful to you.

if you need to launch debugger from the code, write the following line:
System.Diagnostics.Debugger.Launch();
I often use this tecknique in debugging purpose. But it is better to remove it in release version.
If you want to attach to the already running process, open Visual studio, go to menu Debug > Attach to process, find the hosting process and click "Attach" button.

Automated Deployment using CI server

In our project, deployment is always a pain, mostly because of the mistakes done by the release management team. Either they screw up the configuration or get the wrong version installed somehow. We use teamcity as our CI server, and it produces the artifacts as zip files(dll's and exe) which is usually passed on to the release team. My question is, is there a way to automate the whole deployment process?
Is there a commercial tool, which supports this?
We will want to do the following:
Update the config files with environment specific values.
Install windows services to the server.
Upload the UI(WPF) bundle to the centralized location(which is pulled down by another application, sort of a launcher).
Change the DB connection strings.
Do all the above for various environments(like int,uat and prod)
DB deployment since is a separate beast as such, need not be covered in this.
Any best practices, tools or solutions will be highly helpful.
Thanks,
-Mike

I have used TeamCity for some fairly large projects and I have automated every aspect of deployments apart from the database. The main steps I use for each project are:
Get a TeamCity agent installed on the production server
Have the build get everything out of source control (you do have everything in source control right?).
Have a build step that builds and publishes your solution. This can be achieved by adding the following command line argument to your MSBuild call:
/p:Configuration=[Your Config];DeployOnBuild=True;PackageAsSingleFile=False
Your published files (and tranformed config files) will be written to the following directory:
[Your Project Directory]\obj\[Your Config]\Package\PackageTmp
Using a scripting language (in my case Powershell) to copy the published artifacts to your deployment directory and make environment specific changes you mentioned. E.g. extracting archives, copying files, starting/stopping websites etc..
Run any automated testing (e.g. nUnit, Selenium etc...)
I find the best strategy is to have a .Net post-build event that invokes an appropriate powershell script passing in relevant details like the solution path and configuration name (alternatively, I have also had TeamCity pass the environment name to the Powershell script) so that it knows what it needs to do (e.g. Staging, Production etc...). You should find that a scripting language like Powershell can do everything that a person can do (and about 100x faster and 100% reliably).
There is so much content on Powershell out there that you can just google anything you need to do in Powershell and you will get an example. E.g. "powershell deploy WPF", "powershell upload FTP" etc...
In a previous job I needed to deploy windows services remotely and I found that with enough research, I was able to get the MSI for the service to uninstall the existing service and install the new one completely silently (i.e. no dialogs). This will help a lot in your quest for automation. I can elaborate on this if you would like.
Below is an example of a Powershell post build script I generally use:
Note how I use some default parameter values so that I can execute the script directly from my Powershell editor to simulate and test different configurations on my local machine.
param(
[string]$configurationName="Debug",
[string]$sourceDirectory="C:\SVN\<Your local solution location>")
Set-StrictMode -v latest
$ErrorActionPreference = "Stop"
# Load required functions
$private:scriptFolder = & { (Split-Path $MyInvocation.ScriptName -Parent) }
. (Join-Path $scriptFolder DebugBuild.ps1)
. (Join-Path $scriptFolder StagingBuild.ps1)
. (Join-Path $scriptFolder ProductionBuild.ps1)
. (Join-Path $scriptFolder CommonBuildFunctions.ps1)
#Execute appropriate build
switch ($configurationName) {
"Debug" { RunDebugBuild $sourceDirectory }
"Staging" { RunStagingBuild $sourceDirectory }
"Production" { RunReleaseBuild $sourceDirectory }
}
To execute a publish on development machines, I setup a VS publish profile for the solution that is committed to SVN so the other developers can use it. This profile publishes directly to the local deployment directory.

We use TeamCity for our deployments in addition to CI and it works really well. Here are a couple things that may help:
If you're using VS2010, check out the SlowCheetah plugin. It can do the config file transforms to do what you need to replace DB connection strings and other environmental-sensitive variables. These transforms happen automatically when you build based on the selected build configuration.
Check out MSDeploy. While it gets most of it's attention for deploying web applications, it can do a lot of other things, like installing windows services and syncing files to a destination directory. While most people install it as an IIS add-in, it can be installed as a separate service that has no dependencies on IIS.
If you're not using VS2010 (or don't want to use SlowCheetah), here's how we you could handle the config settings:
Create an app config for each different environment (I'm assuming you
have a build configuration set up for each environment). Add the
configuration name to the end of the config file, so in Prod we have
App.config.Prod and QA we have App.config.QA.
Put your complete configuration for each environment in it's respective config file for
that environment.
As part of your build (we use the "BeforeBuild" target in the project file), use msbuild to copy the environmentally specific app.config over the actual one. Here's a custom msbuild target we use to do this:
<PropertyGroup>
<EnvironmentAppConfig>App.config.$(Configuration)</EnvironmentAppConfig>
</PropertyGroup>
<Target Name="ReplaceAppConfig">
<Message Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')"
Text="Copying $(EnvironmentAppConfig) -> App.config" Importance="high" />
<Message Condition="!Exists('$(ProjectDir)$(EnvironmentAppConfig)')"
Text="No $(EnvironmentAppConfig) found. Leaving App.config as is." Importance="high" />
<Copy SourceFiles="$(ProjectDir)$(EnvironmentAppConfig)"
DestinationFiles="$(ProjectDir)App.config"
Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" />
</Target>
Let me know if you need any other details.

Teamcity + Octopus deploy
Octopus for windows service automated deploys

Our release team uses Anthill Pro - this also has ability to do CI, but they just use it to deploy packages (in our case mostly web site code).
The cool thing about Anthill is the whole client(agent)-server setup, so it traverses firewalls, NAT etc with some effort. And it has approval and scheduling workflow.
As far as configs, this is a different beast - unfortunately both devs and release team have to change these, and somehow merge the result. Consider that you want to add new config key, but release team has to add production settings for DB connection. The trick is that devs are not supposed to know production DB connection string.
So this is not automated (in our case anyways).

I'm partial to TeamCity, which is a Jetbrains product, the company that makes the essential ReSharper (no, I don't work for them, drat the luck). TeamCity, at least last time I checked, is a free product for up to 20 users and 20 build configurations. It has some nice auto-build and blame features. Excellent, really.

You mention a Commercial tool...
TFS, or specifically Team Build, completely supports building the code and deploying it. Whenever we build a web app, it auto deploys to our Dev and QA servers. After deployment we have it run through a suite of web tests to ensure everything is functional. Then the real fun begins with our QA team ;)
Although we don't auto deploy to production, we could certainly do that as well.

File or Assembly Cannot be Loaded Error

I am working on a Setup program which creates a .msi file. There is a CustomAction program associated with it which is written in C#. There are three COM object references made in this CustomAction program which are necessary in order for it to work. They are as follows.
Active DS IIS Namespace Provide (C:\Windows\System32\inetsrv\adsiis.dll)
Windows Script Host Object Model (C:\Windows\System32\wshom.ocx)
NetFwTypeLib (C:\Windows\System32\FirewallAPI.dll)
As added information, following are the tasks I use these DLLs in my program for.
To set MIME settings for a particular file type.
To create a desktop shortcut to a folder.
To register a program as a firewall exception
.
Now, here is my problem. When I rebuild the C# program and execute the CustomAction program from within Visual Studio, it works fine and I can get the above three tasks done like a charm. However, when I actually build the .msi and try to execute it and install the program on my system, it gives an error. I'm using a Japanese OS so it gives the error in Japanese so I'll try to translate the error message in to English as best as I can. The error is something like this:
*
File or assembly 'Interop.IISOle,
Version = 1.0.0.0, Culture = neutral,
PublicKeyToken = null', or one of its
dependencies could not be loaded.
Cannot find the file specified.
*
This particular error message is given because it relates to the first dll (adsiis.dll) because it is the one which contains the IISOle namespace. Similarly it gives error messages relates to all the three COM objects which I made references to from my program. Now what I can understand from this is, somehow when this code is inside the .msi file it cannot find the appropriate COM objects. I'm really confused why this happens as the Setup gives the same error when I try to install the program even on the same machine which I used to code the CustomAction. Funnily it executes flawlessly from withing Visual Studio Interface. Please do help me with this. Thanks in advance!
Note that I'm working on Windows Vista Business, but I need my Setup to be able to install on a variety of Windows OS ranging from Windows Server 2003 to Windows 7.

Just encountered this today. Go to "Turn Windows features on or off" and scope out everything under IIS, including the IIS 6 stuff.
Make sure that the feature "IIS Metabase and IIS 6 configuration compatibility" is checked, found under "Internet Information Services" > "Web Management Tools" > "IIS 6 Management Compatibility".

Anton, finally I found out what was wrong.
When I reference, for instance, dsiis.dll then Visual Studio places an Interop module, namely Interop.IISOle.dll inside the bin directory of my CustomAction program. Which is where the CustomAction.exe can also be found. It does the same process when I reference the other two COM objects; wshom.ocx and FirewallAPI.dll. But my actual setup program which is written using Wix copies this CustomAction.exe to some other directory and the .msi uses that particular CustomAction.exe file. The problem occurs since Interop.IISOle.dll (and the others as well) cannot be found there. (The error message said what I needed to look for from the beginning it seems; I was foolish not to look for it but thinking there might be bigger problems)
So this is what I did. I instructed the Wix project to copy those Interop DLL files to the same place where the CustomAction.exe which is used by the installer resides. That solved the problem so easily.
I'm totally a newbie when it comes to Wix, plus we needs to use the CustomAction for 2 and 3 because of some reasons.