|
gariig posted:I call it a fallthrough and Wikipedia seems to use the same semantics. code:
|
# ? Dec 23, 2013 18:20 |
|
|
# ? Jun 4, 2024 14:05 |
|
I have a WCF question, using .NET 4.0: I put together a self-hosted WCF service as a console program which works as expected. The service needs to interact with another application, and this interaction is prone to generating faults that will actually make the service crash. To work around this, I created a second console program to handle the interaction which is called through System.Diagnostics.Process and killed once the interaction is complete. The two services communicate through Net Named Pipes. This way, if there's a major fault the second service will crash but the main one will continue to run. When everything is running in console windows this actually works pretty well, but when I run the primary service as a Windows Service, the two can no longer communicate. Is this a permissions issue, or is it just not possible to use named pipes between a Windows Service and a console program?
|
# ? Dec 23, 2013 18:24 |
|
Admiral Snackbar posted:and this interaction is prone to generating faults that will actually make the service crash. This is a major problem that you should fix.
|
# ? Dec 23, 2013 19:05 |
|
Admiral Snackbar posted:I have a WCF question, using .NET 4.0: I had to do this exact same thing in order to work with a 3rd party native library that sometimes generates access violations, SEHExceptions, etc. that would normally crash the service. I also ended up using WCF named pipes to handle the IPC, but I never had any problem communicating between the two whether I was running a unit test or running the real service. It could be a permissions issue depending on which privileges you're running the service under.
|
# ? Dec 23, 2013 19:15 |
|
ManoliIsFat posted:Yup. Fun thing to note: in C#, you can't fall through conditions that have statements in them. In C and C++ (and Java too, IIRC) you could do this, but it usually is not what you intended to have happen and causes more trouble than it's worth, so they don't allow it in C#. But if that's what you intended you can use "goto case" to jump to another case statement.
|
# ? Dec 23, 2013 19:22 |
|
Ithaqua posted:This is a major problem that you should fix. Unfortunately the faults are coming from the third party application and even try-catch blocks don't save the service from crashing. I'm trying to isolate the fundamental problem, but in the mean time I need something to get the job done. AWWNAW posted:I had to do this exact same thing in order to work with a 3rd party native library that sometimes generates access violations, SEHExceptions, etc. that would normally crash the service. I also ended up using WCF named pipes to handle the IPC, but I never had any problem communicating between the two whether I was running a unit test or running the real service. It could be a permissions issue depending on which privileges you're running the service under. The installer is using ServiceAccount.LocalSystem. Is that what you used?
|
# ? Dec 23, 2013 19:40 |
|
Admiral Snackbar posted:Is this a permissions issue, or is it just not possible to use named pipes between a Windows Service and a console program? I'm using a WCF NetNamedPipeBinding in a windows service, works fine.
|
# ? Dec 23, 2013 21:21 |
|
Admiral Snackbar posted:Unfortunately the faults are coming from the third party application and even try-catch blocks don't save the service from crashing. I'm trying to isolate the fundamental problem, but in the mean time I need something to get the job done. There are uncatchable exceptions when serialization or deserialization fail (it will just kill the connection, not even letting you log it, bypassing the unhandled exception handling), but to my knowledge there is no way an outside client connecting to a WCF service can cause that service to crash. You should make sure you have your fault contracts setup, put fault handlers and unhandled exception handlers in place, etc.
|
# ? Dec 23, 2013 22:33 |
|
Ithaqua posted:Yeah, in that case you're stuck with the extra changesets. You can always use "Find Changesets" and exclude the service account's changesets in order to see just your own. What are the extra changesets from? Checking in the built products into source control? I thought that we allowed you to drop the build into the file container service now, as opposed to just checking in the products into version control. The file container service is light-weight and you can ask for the entire contents of the container as a ZIP file (although the server ZIPs up the content on the fly for each request, lol). Edit: I see now that you discovered the feature I'm talking about. Great!
|
# ? Dec 24, 2013 00:58 |
|
Having a hell of a time trying to learn WPF, particularly databinding. Tutorials I've found don't help at all. I have an sql database I wanted to retrieve info from, I have a stored procedure and a function that runs it to return a datatable. Then, I just run code:
Then, in the xaml markup for the grid, I added code:
|
# ? Dec 24, 2013 19:56 |
|
bobua posted:Having a hell of a time trying to learn WPF, particularly databinding. Tutorials I've found don't help at all. Well, first off, please don't bind data tables directly to anything. Use a data access layer and return a strongly-typed model object representing your data. Things will make sense if you look for an MVVM (model-view-viewmodel) tutorial. Once you have a viewmodel, you just set the viewmodel as your window's datacontext, then you can bind directly to any properties in your viewmodel by just specifying {Binding SomeProperty}. The tricky part is that there are about a million ways to specify what your data context should be. The easiest is to just pop open MainWindow.xaml.cs (or whatever your window is named) and set this.DataContext = new WhateverViewModel(); Make sure your viewmodel implements INotifyPropertyChanged, of course. Any MVVM tutorial will cover that stuff.
|
# ? Dec 24, 2013 21:03 |
|
quote:Well, first off, please don't use data tables directly for anything. fixed that for ya. Happy festivus.
|
# ? Dec 25, 2013 09:36 |
|
Is Log4Net still the go-to logging framework for C#/.NET 4.5 projects? Does it play well with ASP.NET?
|
# ? Dec 25, 2013 10:20 |
|
NLog is worth looking at two but either options will play well with any .NET app.
|
# ? Dec 27, 2013 06:38 |
|
Ender.uNF posted:There are uncatchable exceptions when serialization or deserialization fail (it will just kill the connection, not even letting you log it, bypassing the unhandled exception handling), but to my knowledge there is no way an outside client connecting to a WCF service can cause that service to crash. It wasn't a client causing the crashes, it was a process called by the service itself. It turns out the issue was with the account the service was running on - as soon as I switched it away from Local System everything worked ok again. I appreciate everyone's feedback on this - thanks!
|
# ? Dec 27, 2013 15:44 |
|
OK, so, I'm just going to go ahead and ask this even though I think it's probably a stupid question. I'm trying to start getting into unit tests. I haven't ever really used them before. I'm working on an MVC project with data being persisted with EF CodeFirst (it's a week old so there aren't mountains of legacy stuff or anything). So it seems like the preferred way of doing this is creating an interface, then having my data store implement that interface, so that I can also have a pretend repository implementing it that I'll use in my tests. I mean, OK, I get that in theory, but how does this work in the real world without me totally reimplementing all the canned stuff I'm getting with the ApplicationDbContext and the various methods UserManager is offering to do user-related stuff (using ASP.Net identity instead of handrolled stuff)? Most of the examples I see are talking about rolling your own, which makes the concept easy to understand but I'm not seeing how it's supposed to work in an actual project instead of just something that's a toy. I realize there are huge books on this subject but I'm also learning Entity and MVC through this project so I'm not too keen on reading a big tome just on DI or unit testing; I'd like some material that I could basically look at in one sitting. Also, while there are probably valid reasons not to use some of the canned stuff I'm talking about the project I'm working on is on a tight schedule where being able to use premade stuff is a big help. edit: In case this is like total gibberish I'm talking about starting with the MVC project type that already has identities and login/registration all built in out of the box. RICHUNCLEPENNYBAGS fucked around with this message at 05:30 on Dec 28, 2013 |
# ? Dec 28, 2013 04:39 |
|
RICHUNCLEPENNYBAGS posted:OK, so, I'm just going to go ahead and ask this even though I think it's probably a stupid question. The role/membership provider uses a lot of static classes, which makes life trickier. Encapsulate all of the membership provider stuff up in a class and then inject an implementation of that class to your controllers. Then you can mock the data it returns.
|
# ? Dec 28, 2013 16:47 |
|
Ithaqua posted:The role/membership provider uses a lot of static classes, which makes life trickier. Encapsulate all of the membership provider stuff up in a class and then inject an implementation of that class to your controllers. Then you can mock the data it returns. So you mean I should just create another class that's going to wrap all the UserManager methods?
|
# ? Dec 28, 2013 17:10 |
|
RICHUNCLEPENNYBAGS posted:So you mean I should just create another class that's going to wrap all the UserManager methods? Yes, and put that behind an interface. Then you can use standard DI practices to make it testable. Another option is to use the Fakes framework to create shims for the UserManager, but I recommend against using shims. It hides the problem (untestable code), it doesn't solve the problem.
|
# ? Dec 28, 2013 17:32 |
|
I mean... am I really making that better by building another class that's just going to call those methods? I'm missing something here.
|
# ? Dec 28, 2013 18:13 |
|
RICHUNCLEPENNYBAGS posted:I mean... am I really making that better by building another class that's just going to call those methods? I'm missing something here. It's for testability and maintainability. If you code against a concrete class rather than an interface, you run into two problems: a) If the nature of that class changes and you want to use the updated version, you need to go through all your code and fix it. b) You will not be able to run true unit tests because they'll be running real calls - so you won't be able to test your own logic in isolation. Sometimes you can get away with doing that if the calls made are deterministic, but you don't want to actually, say, talk to a real database when doing unit tests.
|
# ? Dec 28, 2013 18:25 |
|
RICHUNCLEPENNYBAGS posted:I mean... am I really making that better by building another class that's just going to call those methods? I'm missing something here. Yes, you are. You're isolating calls to the static methods behind something replaceable. Let's say you decide to throw away the Microsoft membership provider and write your own. Now you have only one place you need to change: The class you wrote that encapsulates the functionality of the membership provider. Here's a silly example: code:
|
# ? Dec 28, 2013 18:30 |
|
OK, I think I'm following now. So if I can go ahead and ask a dumb follow-up question: that seems pretty straightforward. What's the advantage of using a whole DI framework?
|
# ? Dec 28, 2013 19:05 |
|
RICHUNCLEPENNYBAGS posted:OK, I think I'm following now. It's useful when you have a huge dependency graph that you don't want to deal with constructing manually. For example, if you need a Foo, which takes an IBar, and your IBar implementation requires an IBaz and an IFrobble implementation, and your IFrobble implementation requires an IButts, it gets daunting pretty quickly. A good DI container lets you specify how everything maps together so you can just say "Give me the appropriately constructed IFoo, please" and it shits you out an object that's put together properly.
|
# ? Dec 28, 2013 19:28 |
|
RICHUNCLEPENNYBAGS posted:OK, I think I'm following now. If you want a book on unit testing I'm enjoying The Art of Unit Testing. It goes over all of the stuff Ithaqua and RICHUNCLEPENNYBAGS are talking about in depth. It goes over patterns and tools. After that there are a bunch of other books that The Art of Unit Testing mentions as even deeper dives into certain subjects.
|
# ? Dec 28, 2013 22:16 |
|
Also read up on SOLID design principles, which are what enable unit-testable code.
|
# ? Dec 29, 2013 00:35 |
|
RICHUNCLEPENNYBAGS posted:OK, I think I'm following now. I'd add that if you're creating a simple project, you don't need a full DI framework, and can do it by hand. If you follow good practices, you should still wind up with something like a composition root, the location in your program where you bring all your dependencies together. Later on it'd be pretty trivial to replace your hand-rolled DI with a framework if you decide that it's worth it.
|
# ? Dec 30, 2013 17:55 |
|
MVC question: If I put a DbContext in the constructor of a controller, what is the lifecycle? Will it be disposed of when a request is handled? Does it cause concurrency issues?
|
# ? Dec 31, 2013 14:55 |
|
RICHUNCLEPENNYBAGS posted:MVC question: If I put a DbContext in the constructor of a controller, what is the lifecycle? Will it be disposed of when a request is handled? Does it cause concurrency issues? It's finalizer will be called when the controller is done serving a request. Whether or not it is properly disposed of is up to you.
|
# ? Dec 31, 2013 15:42 |
|
That's not true, DBContext has it's own lifetime, it could be static within the controller factory for all you know. Usually it's managed by the IOC container of choice.
|
# ? Dec 31, 2013 17:01 |
|
Funking Giblet posted:That's not true, DBContext has it's own lifetime, it could be static within the controller factory for all you know. Usually it's managed by the IOC container of choice. I will usually wrap my db calls in a disposable layer and put that in using blocks in my controller. Please tell me I'm doing something right...
|
# ? Dec 31, 2013 17:57 |
|
aBagorn posted:I will usually wrap my db calls in a disposable layer and put that in using blocks in my controller. That's how I always do it. I don't want it sitting around forever, with God knows what changes happening when I do a SaveChanges(). It seems really cheap creating a new DBContext after the first one.
|
# ? Dec 31, 2013 17:59 |
|
Funking Giblet posted:That's not true, DBContext has it's own lifetime, it could be static within the controller factory for all you know. The lifetime of the DBContext is the least of someone's worries if they're using it as a static singleton in an ASP site!
|
# ? Dec 31, 2013 19:01 |
|
RICHUNCLEPENNYBAGS posted:MVC question: If I put a DbContext in the constructor of a controller, what is the lifecycle? Will it be disposed of when a request is handled? Does it cause concurrency issues? DbContext shouldn't be in your controller at all. For the love of god, use a data access layer.
|
# ? Dec 31, 2013 19:06 |
|
The specific use I have in mind is instantiating a new instance DbContext in the constructor and then disposing of it in the controller's Dispose method.
RICHUNCLEPENNYBAGS fucked around with this message at 00:18 on Jan 1, 2014 |
# ? Jan 1, 2014 00:15 |
|
RICHUNCLEPENNYBAGS posted:The specific use I have in mind is instantiating a new instance DbContext in the constructor and then disposing of it in the controller's Dispose method. Don't do that. Use a data access layer and wrap your DbContext in a using block.
|
# ? Jan 1, 2014 01:45 |
|
I get why you're saying that but I just wanted to know if the controller's Dispose was going to happen with every request.
|
# ? Jan 1, 2014 08:12 |
|
RICHUNCLEPENNYBAGS posted:I get why you're saying that but I just wanted to know if the controller's Dispose was going to happen with every request. Yes.
|
# ? Jan 1, 2014 17:27 |
|
Why not have a disposable data access class instead of wrapping every single method in using?
|
# ? Jan 2, 2014 14:05 |
|
|
# ? Jun 4, 2024 14:05 |
|
RICHUNCLEPENNYBAGS posted:Why not have a disposable data access class instead of wrapping every single method in using? Because there's no upside to keeping a database connection around longer than necessary, and a bunch of downsides. Just follow the repository pattern and everything will be beautiful.
|
# ? Jan 2, 2014 15:40 |