|
Does anyone have any tips for streamlining Windows Service development? I started working on a large, mature system two months ago, which runs on a fairly baffling ecosystem of virtual machines. Most of these VMs are running windows services, which I need to develop. I've got batch scripts that, whenever I recompile a particular service, automatically uninstalls it, copies the new files to the VM, reinstalls the service, and then starts it. I then attach the debugger to the process running on the VM if I need to debug. This is all fairly nice, but the process still feels very unweildy, and compiling and running the code takes up to a minute, which is frustrating me more than it should. Are there any ways to streamline this process that I haven't noticed? I'm running visual studio 2012 pro, but I can get a upgrade to 2013 pro if needed.
|
#
¿
Jul 22, 2014 15:57
|
|
|
|
| # ¿ May 2, 2024 06:22 |
|
|
Bognar posted:Take all of your interesting code and put it in a separate project, then debug through a console app? This will work if you can test on your dev machine and not have to deploy to a VM. Destroyenator posted:Depending how much scope you've got to mess with them I've used http://docs.topshelf-project.com/en/latest/overview/faq.html before and it's pretty good. You write your service as a console app with this wrapping it up. Lets you run from the command line for testing and adds install/uninstall command line flags which do that junk for you. Malcolm XML posted:Chef, puppet and Powershell DSC ManoliIsFat posted:TopShelf was huge for me. Being able to just debug right in to your service code without doing all that debugger attach (and maybe building in a startup-delay so you can attach the debugger in time). And then using TopShelf to install the service instead of making a Setup/Installer project for all of it. Thanks for the suggestions. TopShelf and Puppet definitely looks interesting, I'm looking into them right now. If TopShelf is easy to integrate into the preexisting project, it looks like it'll be a huge timesaver when compared to deploying to vm via batch script. I've also started using unit tests to test individual pieces of code, which is a huge improvement over accessing the frontend and activating the functionality from there. I graduated this spring and got hired two months ago to dust off a 100k+ loc system (.net backend, asp and extjs frontend and two databases, interfacing with two different black-box systems, with the whole shebang running on ten virtual machines. Overwhelmed doesn't even begin to describe how I felt the first couple of weeks.  ). The system has basically been dormant for the past year, after the only guy working on it quit. They're now renewing development on it, and the first stage was hiring me. My job for the past two months has basically been to figure out how to get this monster running, and set up development procedures and tools to lubricate the development that's starting on the system. Two weeks from now, there are two other developers starting on the project and the goal is to have the environment and procedures set up and ready to go. Geisladisk fucked around with this message at 18:05 on Jul 24, 2014 |
|
#
¿
Jul 24, 2014 17:59
|
|
|
I'm developing a Windows service. One class in this service references an external DLL. When I run the unit tests for the service, which are in a separate project, the class runs fine; The DLL is loaded, the code executes as intended, and all is well. When I run the service itself, and the code executes, I get a bad format exception on the DLL. The service itself is 64 bit, and I've tried using both 32 bit and 64 bit DLLs, and it seems to make no difference. Both the unit test project and the service project are using .NET version 4, and compiled using 64 bit architecture. I've googled around and found nothing related - Can bad format exceptions be caused by anything other than bit architecture mismatch? 
|
|
#
¿
Apr 24, 2015 14:01
|
|
|
EssOEss posted:Are you sure it is trying to use the correct DLL? I have never seen that error for any other reason and it seems unlikely to be the reason. Yup. As I said, I've tried it with both a 32 bit and 64 bit version of the DLL, with the same results. quote:Your wording on "Compiled using 64 bit architecture" makes me think perhaps the bitness of .NET services is not entirely clear to you. It is essentially just an enum field in the binary, set a compile time. There is no other difference and it does not matter if you use 32-bit or 64-bit .NET to build your app. I dunno. Possibly. I just meant that I built the service as a 64-bit executable, I wasn't referring to the bitness of the .NET version I used. quote:When you run the service itself, do you see it listed as 32-bit or 64-bit in Task Manager? As a next step, use Process Monitor to find out what exactly is the DLL it tries to load and then verify that the bitness of that DLL matches. It's listed as 64 bit in the Task Manager. I loaded up Process Monitor just now, and confirmed that the service is in fact loading the correct DLL.
|
|
#
¿
Apr 24, 2015 14:36
|
|
|
I've got a (possibly stupid) question regarding threadpools. Our application's backend uses Smart Thread Pool (http://www.codeproject.com/Articles/7933/Smart-Thread-Pool) to manage our threads. Some tasks that are run periodically need to process lots (hundreds of thousands) of pieces of data. Our extremely lazy implementation for this to use a thread pool like a queue; Each piece of data spawns a task, which is added to the thread pool qieie. The thread pool has a limit of how many are processed at each time, while the rest of the tasks are pending until a slot opens up for them and they are processed. Is there any drawback to using a threadpool like a queue, and having hundreds of thousands of pending tasks? Cursory testing doesn't reveal any significant drawbacks, memory usage is just fine. But this just feels like a unbelievably lazy and wrong implementation, for some reason. I'd love for someone to either tell me I'm an idiot and my implementation is idiotic before I ship this. e: "Threads" -> "Tasks" Geisladisk fucked around with this message at 18:16 on Nov 23, 2015 |
|
#
¿
Nov 23, 2015 17:13
|
|
|
Bognar posted:EDIT: Oh wow, this Smart Thread Pool library has been around for over a decade. Most of the features it touts are available in .NET now. If the code using it isn't huge, I'd suggest ripping it out entirely and just using the features available in the language. It will be easier for others to maintain and easier to find information about. It's a pretty massive system that is well into it's second decade. I'm pretty loathe to rip out such a central piece of the system just because the library that provides it is old and lame, if it works.  ljw1004 posted:Just to reinforce that, a threadpool which has lots of blocked threads (e.g. inside Thread.Sleep, or waiting synchronously for a file/network read to finish) is the worst possible use of a threadpool. It will take up lots of memory and confuse the threadpool. Yes, that's what I meant. Each piece of data spawns a task, not a thread. My bad.
|
|
#
¿
Nov 23, 2015 18:15
|
|
|
|
| # ¿ May 2, 2024 06:22 |
|
|
Under ASP .NET running on a IIS server, can I somehow log when a browser starts uploading files via HTTP? By the time ASP .NET starts handling the request, the upload seems to be complete. IIS seems to handle the upload itself behind the scenes. I'm interested in precisely when the user starts the upload, and when it stops.
|
|
#
¿
May 24, 2016 11:16
|
|