.Net Questions Megathread Part 2

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .Net Questions Megathread Part 2

«‹›440 »

ManoliIsFat: Oct 4, 2002

gariig posted:

I call it a fallthrough and Wikipedia seems to use the same semantics.

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#.

code:

            int x = 2;

            switch (x)
            {
                case 1:
                case 2:
                    Console.WriteLine("whoa");
                default:
                    Console.WriteLine("test");
                    break;
            }

In C#, the compiler will complain "Control cannot fall through from one case label to another).

# ? Dec 23, 2013 18:20

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 00:44

Admiral Snackbar: Mar 13, 2006; OUR SNEEZE SHIELDS CANNOT REPEL A HUNGER OF THAT MAGNITUDE

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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

AWWNAW: Dec 30, 2008

Admiral Snackbar posted:

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?

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

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

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#.
code:
            int x = 2;

            switch (x)
            {
                case 1:
                case 2:
                    Console.WriteLine("whoa");
                default:
                    Console.WriteLine("test");
                    break;
            }
In C#, the compiler will complain "Control cannot fall through from one case label to another).

But if that's what you intended you can use "goto case" to jump to another case statement.

# ? Dec 23, 2013 19:22

Admiral Snackbar: Mar 13, 2006; OUR SNEEZE SHIELDS CANNOT REPEL A HUNGER OF THAT MAGNITUDE

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

epswing: Nov 4, 2003; Soiled Meat

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

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

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.

The installer is using ServiceAccount.LocalSystem. Is that what you used?

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

Tellara: May 2, 2003; Quality Custom Glassware Since 1923

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

bobua: Mar 23, 2003; I'd trade it all for just a little more.

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:

gridControl1.ItemsSource = myclass.datatable;

and hurrah, my data is in the grid. That didn't feel very wpfish though, so I set about trying to figure out this databinding stuff. First thing I figured is that I need to instantiate myclass in the xaml, so I tried doing that in the window.resources area with <local:myclass x:key="mc" x:Name="mc" /> I used a key and a name, because at this point I'm not really sure what the difference is.

Then, in the xaml markup for the grid, I added

code:

DataContext="{DynamicResource mc}" ItemsSource="{Binding datatable}"

just because I saw it in a stackoverflow answer that seemed relevant... but I'm honestly at a complete loss on databinding syntax, and of course this doesn't work. I had never even seen dynamicresource in any of the tutorials I read, and nothing I see ever really spells it all out. It always seems wildly different, too.

# ? Dec 24, 2013 19:56

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

bobua posted:

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:
gridControl1.ItemsSource = myclass.datatable;
and hurrah, my data is in the grid. That didn't feel very wpfish though, so I set about trying to figure out this databinding stuff. First thing I figured is that I need to instantiate myclass in the xaml, so I tried doing that in the window.resources area with <local:myclass x:key="mc" x:Name="mc" /> I used a key and a name, because at this point I'm not really sure what the difference is.

Then, in the xaml markup for the grid, I added
code:
DataContext="{DynamicResource mc}" ItemsSource="{Binding datatable}"
just because I saw it in a stackoverflow answer that seemed relevant... but I'm honestly at a complete loss on databinding syntax, and of course this doesn't work. I had never even seen dynamicresource in any of the tutorials I read, and nothing I see ever really spells it all out. It always seems wildly different, too.

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

wwb: Aug 17, 2004

quote:

Well, first off, please don't use data tables directly for anything.

fixed that for ya. Happy festivus.

# ? Dec 25, 2013 09:36

Chuu: Sep 11, 2004; Grimey Drawer

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

wwb: Aug 17, 2004

NLog is worth looking at two but either options will play well with any .NET app.

# ? Dec 27, 2013 06:38

Admiral Snackbar: Mar 13, 2006; OUR SNEEZE SHIELDS CANNOT REPEL A HUNGER OF THAT MAGNITUDE

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.

You should make sure you have your fault contracts setup, put fault handlers and unhandled exception handlers in place, etc.

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

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

RICHUNCLEPENNYBAGS posted:

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.

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

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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:

public interface IUserManager
{
    bool ValidateUser(string userName);
}

public class RealUserManager : IUserManager 
{
    public bool ValidateUser(string userName) 
    {
        return UserManager.ValidateUser(userName);
    }
}

public class FooController : Controller 
{
    private IUserManager userManager;
    public FooController(IUserManager userManager)
    {
        this.userManager = userManager;
    }

    public FooController() : this(new RealUserManager()) { }
}

Now if you want to test your FooController, you can give it an implementation of IUserManager that does whatever you want, totally decoupled from the membership provider you're using in your real system.

# ? Dec 28, 2013 18:30

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

RICHUNCLEPENNYBAGS posted:

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?

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

gariig: Dec 31, 2004; Beaten into submission by my fiance; Pillbug

RICHUNCLEPENNYBAGS posted:

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?

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

Dietrich: Sep 11, 2001

Also read up on SOLID design principles, which are what enable unit-testable code.

# ? Dec 29, 2013 00:35

Rooster Brooster: Mar 30, 2001; Maybe it doesn't really matter anymore.

RICHUNCLEPENNYBAGS posted:

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?

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

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

Huragok: Sep 14, 2011

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

Funking Giblet: Jun 28, 2004; Jiglightful!

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

aBagorn: Aug 26, 2004

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

ManoliIsFat: Oct 4, 2002

aBagorn posted:

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...

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

PhonyMcRingRing: Jun 6, 2002

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

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

RICHUNCLEPENNYBAGS: Dec 21, 2010

Why not have a disposable data access class instead of wrapping every single method in using?

# ? Jan 2, 2014 14:05

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 00:44

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .Net Questions Megathread Part 2

«‹›440 »