WorkerThread posted:

Dependencies are transitive (mostly).

What version of the full framework are you using? In my experience, even in versions supposedly compatible with netstandard2.0, there is just a fractal of issues that prevent you from doing anything without sinking hours into workarounds, etc.

Maybe consider checking out the Core 3.0 preview, where I believe they are adding support for WPF.

quote:

e: also, static initializers in your library?

Rocko Bonaparte posted:

I was trying to watch for file changes in a PowerShell script and got bit. Specifically, I tried to use System.IO.FileSystemWatcher. I think there's a PowerShell thread but my questions are a bit more specific about .NET concurrency. I did something like this:

code:

$fsw = New-Object IO.FileSystemWatcher $folder, $filter -Property @{IncludeSubdirectories = $false;NotifyFilter = [IO.NotifyFilters]'FileName, LastWrite'}
...
Register-ObjectEvent $fsw Created -SourceIdentifier FileCreated -Action {
    $found_files = $true
}

I can see the code get called but $found_files won't become $true from a loop polling on the outside. If I changed $found_files to a list and add the filename to it instead, then that would carry forward. It smelled to me like the boolean was a primitive that was not getting properly updated between threads (memory fence, etc). So it seemed like I had more than one thread involved here. I then tried to use System.Threading.Monitors, but it locked up on the Wait() statement. The FileCreated action wouldn't fire. It sounded to me like that event fires on the same thread instead of coming in from another thread.

BTW, I was using Monitor statements because there isn't a lock keyword in PowerShell, so I'd basically lock using Monitor.Enter, and then use Pulse/Wait depending on whether I was in that event callback (Pulse) or the invoking parent code (Wait).

I can try to post a more complete example, but I would have to fully reconstruct what I was doing. Right now, I'm just polling for the existence of the file, but I always try to make an effort to avoid polling.

LongSack posted:

The startup targets .NET Framework 4.7.something. Even though the DAL is in a separate directory, and all the dependent libs exist there, the runtime is expecting to find them in the directory with the startup project. So what’s the point of separating out the code into a separate library? It’s not like this code (in this instance, at least) is reusable, unless I came up with a different program that used the same database.

And yes, I am looking forward to 3.0, but I’m not comfortable using preview releases

LongSack posted:

OK, I’ll bite. The sole purpose of the initializer is to instantiate and register the Mapper and to register all the DAL classes. Why shouldn’t it be static? It tracks whether it had already been initialized and won’t do it twice if reinvoked. I mean, functionally, what’s the difference between DAL.Initialize() and new DALInitializer.Initialize()?

WorkerThread posted:

That sounds a little strange. Do you have any funky custom MSBuild stuff? How are you publishing your app or are you running it straight from VS? Also I'm assuming you're using packages.config and not PackageReference

quote:

I mean, like that, nothing

There is value in letting your application control the configuration its dependent libraries.

I'm definitely a stupid goon so don't take my word as gospel, but:

1. your data layer can be reconfigured without recompiling
   
2. application startup code is in one place
   
3. tests become much, much simpler to write (also helps if you use interfaces)
   

My day job is to do software architect garbage, so obviously those points are a lot more important in that context, but I'd argue they're still worthwhile for solo projects, especially if you're using it as part of a portfolio/demo.

NihilCredo posted:

Did you add the DAL project dependency as a project reference or directly as an assembly reference? The latter is a "dumb" reference that doesn't autoupdate, you normally want the former.

quote:

Also, every reference has a "Copy to output folder" property (visible both in the .**proj file and in the Visual Studio properties), which should default to yes but might have been turned off for some reason.

quote:

Also, static and instance initializers are both bad. If your class needs to perform some operations that may or may not succeed before it's ready to fulfill its public APIs, then make the constructor private and expose a static factory method that can return a failure state.

LongSack posted:

The references are being copied to the output directory - of the library. For some reason, the runtime is looking for them in the directory of the startup project

LongSack posted:

The references are being copied to the output directory - of the library. For some reason, the runtime is looking for them in the directory of the startup project

SirViver posted:

This is pretty much the expected/standard .NET assembly load behavior. All your assemblies must* be placed next to the executable respectively executing assembly. Anything else requires configuration or manual dynamic loading of assemblies or implementing your own assembly resolve logic.

* Of course, that is not the whole truth: see here.

LongSack posted:

Project reference (specifically using the "Project Dependencies" menu item)

bobua posted:

I must not have ever understood .net core. I always thought of it as completely cross platform. Hearing that wpf is coming in core 3.0 makes me think I was wrong. What exactly does wpf in core mean?

raminasi posted:

If your simplified version isn't too simplified, your problem isn't threading, it's scoping. As written, every time the handler files, it creates a new $found_files, sets it to true, and throws it away. If you initially declare $found_files outside of the handler it should work.

NihilCredo posted:

Also, static and instance initializers are both bad. If your class needs to perform some operations that may or may not succeed before it's ready to fulfill its public APIs, then make the constructor private and expose a static factory method that can return a failure state.

LongSack posted:

Going back to this, let me ask ...

Given a library that has over 100 classes (each table in the database has a POCO entity class, an observable DTO class, a config class (for use in ApplyConfiguration), a DAL class, and a DAL interface), where would you put code that is needed to Initialize the library as a whole, rather than any individual class?

Before the library is usable, I need to configure, instantiate and register the AutoMapper Mapper class, and register the concrete DAL classes that serve the interfaces.

I recognize that an exception in a static constructor renders the class unusable, but honestly, an error during the initialization of the DAL library is not recoverable anyway.

So, if static initializers are bad, what’s the alternative? Factory methods are out, since I’m initializing the library as a whole, not any individual class. Also, keep in mind that class instantiation is not done by a framework (like in ASP.NET Core), so I can’t do DI just by putting parameters in a constructor. I have to go out and grab dependencies from the container, like

C# code:

public void Foo()
{
    var cdal = Registrar.Get<ICharacterDAL>();
        .
        .
        .
}

So, given these parameters, what is a good solution for initializing the library? Genuinely curious. TIA

NihilCredo posted:

words

LongSack posted:

Xik posted:

IMapper is in the constructor of every class that needs it and DI resolves it. Under normal circumstances there is just one global IMapper object containing all the mappings for every type.

quote:

For where it goes, you usually put all that configuration and registration in your main assembly where it will execute once on application startup, somewhere sane people don't unit test. In a WPF application, that might be an overridden Application.OnStartup(StartupEventArgs).

LongSack posted:

Except that this isn’t ASP.NET where the framework instantiates everything and DI happens by magic. My DAL classes all start out like

C# code:

public class FooDAL : IFooDAL
{
    private readonly IMapper _mapper;

    public FooDAL()
    {
        _mapper = Registrar.Get<IMapper>();
    }
    etc...
}

OK, so App.xaml.cs is a good place. Thank you.

Rocko Bonaparte posted:

Not a problem with scoping. I've already obsessively copy-pasted the variable from outside to all places of use just to make sure my beady eyes didn't mess it up somewhere.

I tidied things a bit and put it up on Pastebin: https://pastebin.com/hkY5SMBL

I also have the Monitor statements in there, but commented out. If you run this and put some xxx_returncode.txt file in C:\temp\poll_folder, then you'll see the event listener kick off, which should set $found_files to true. However, it's just a parade of false in the poll loop.

At any rate, I'd prefer not to poll and would rather just block and get kicked on either a timeout or a stimulus from the event. I can't figure out how to make that work. Monitor locking up like it did implies to me the event runs on the same thread as the main loop. When I call Monitor.Wait, I think I starve the event handler since the events don't fire at all any more. I'm assuming it's coroutine/async shenanigans, but I'm not familiar enough with FileSystemWatcher to know what how its events work.

WorkerThread posted:

What prevents you from using constructor injection? You don't need a container at all. Back before I settled on Microsoft.Extensions.DependencyInjection, I would create/configure all my classes in the application root (Program.cs/App.xaml.cs/etc) manually. No magic required

I'm not saying that was especially smart, as using containers is actually very simple, but it's certainly possible.

LongSack posted:

I’m using my own homebrew DI container which doesn’t support it. I guess it’s time to look at Microsoft’s DI.

Does it support “object registration” if that’s the correct term? Like, my DI class supports “register” (a new instance is created every call), “register singleton” (the first call caches the created object which is returned on subsequent calls) and “register object” which adds an instantiated object directly to the cache, so it’s like “register singleton” except that the object is provided at registration time).

WorkerThread posted:

Got it. Microsoft's container should feel pretty familiar, then, except it supports constructor injection. You've got three scopes available-- Singleton, Scoped, and Transient (like what you called "register" above). You can also provide pre-built instances as well for tricky to construct types.

I prefer that container because it doesn't really do a lot of magic for you in the background: no auto-registration or assembly scanning, etc. I like to see the registrations for each type in use by my app.

LongSack posted:

Thanks! I’ll take a look at it tomorrow.

LongSack posted:

Oh, and if you’re wondering why use Expression<Func<foo, bool>> rather than just Func<foo, bool>, it’s because Where with the latter returns an IEnumerable<foo>, so you can’t add, say, an .AsNoTracking(). Where with the former returns an IQueryable<foo>, so you can.

LongSack posted:

Rewrote the (thankfully only five I had already written) DALs to use Microsoft’s DI using constructor injection and finished the other 22 today. It was surprisingly (to me) easy to do. Then, in App.xaml.cs I created the ServiceCollection and registered all my services, and flipped that into a ServiceProvider. Now what do I do with that to make it available to the rest of the program? Ended up registering it with my original DI container.

beuges posted:

Just so you know, there are .AsQueryable<T> and .AsEnumerable<T> methods that are available from entity framework that will transform from one to the other.

LongSack posted:

Rewrote the (thankfully only five I had already written) DALs to use Microsoft’s DI using constructor injection and finished the other 22 today. It was surprisingly (to me) easy to do. Then, in App.xaml.cs I created the ServiceCollection and registered all my services, and flipped that into a ServiceProvider. Now what do I do with that to make it available to the rest of the program? Ended up registering it with my original DI container.

Haven’t got to the point where I can actually run any of the code yet, so hopefully it all works.

Also had a bit of a breakthrough.

My DAL classes have standard Insert, Update and Delete methods, plus 2 types of read methods: Get methods return an IEnumerable always. If the read returns no rows, it returns an empty collection, but they always return a collection. In contrast, Read methods return either an object, or null, since Read is used to grab a single item, where Get is used to get a collection.

I realized, in a blinding flash of the obvious, that these various methods were basically the same except for the Where clause.

I realized that I could write a single Get method and pass it an Expression<Func<foo, bool>> parameter with a default value of null.

So now my GetForCharacter(int cid) method can simply be Get(x => x.CharacterId == cid);

Even the reads can use the same method. Read(int id) becomes Get(x => x.Id == id).SingleOrDefault();

This localizes all of the read code into a single method, which helps with maintainability.

Maybe this is obvious to y’all, but it was a breakthrough for me.

Oh, and if you’re wondering why use Expression<Func<foo, bool>> rather than just Func<foo, bool>, it’s because Where with the latter returns an IEnumerable<foo>, so you can’t add, say, an .AsNoTracking(). Where with the former returns an IQueryable<foo>, so you can.

Cuntpunch posted:

What do you mean 'the rest of the program'?

You've setup your container at the application root. Everything your program needs should be configured and ready to go, shouldn't it?

LongSack posted:

Well, constructor injection only works with classes being instantiated by DI, right? This isn't ASP.NET Core where everything is basically instantiated by the framework. Let's take my MainViewModel. It needs access to services in DI, so how does it get access to the ServiceProvider? It gets instantiated in the code-behind of the main Window as

C# code:

    DataContext = new MainViewModel();

If i stick an IServiceProvider constructor parameter, the code-behind will have to get access to it somehow in order to pass it to the ViewModel.

I suppose I could move the DI initialization code into the code-behind of the main Window and then it could pass the provider to the VM, but that feels like the wrong place for that (that code is currently in App.xaml.cs)

LongSack posted:

Well, constructor injection only works with classes being instantiated by DI, right? This isn't ASP.NET Core where everything is basically instantiated by the framework. Let's take my MainViewModel. It needs access to services in DI, so how does it get access to the ServiceProvider? It gets instantiated in the code-behind of the main Window as

C# code:

    DataContext = new MainViewModel();

If i stick an IServiceProvider constructor parameter, the code-behind will have to get access to it somehow in order to pass it to the ViewModel.

I suppose I could move the DI initialization code into the code-behind of the main Window and then it could pass the provider to the VM, but that feels like the wrong place for that (that code is currently in App.xaml.cs)

New Yorp New Yorp posted:

Constructor injection just means "an implementation is passed in via the constructor".

DataContext = new MainViewModel(someRequiredServiceImplementation);

However, the way it typically works with a DI container is that you tell the DI container "give me a MainViewModel that's constructed correctly" and it handles creating it for you with all of the appropriate dependencies already injected.

Cuntpunch posted:

You've referenced ASP.NET a few times now and I think you may need to peek behind the curtain and see the real Wizard of Oz - because ASP.NET has some standard behavior around its DI stuff, but there's really nothing magic about it. It's just hiding the boilerplate from you.

In the case of XAML based stuff, I've tended to follow Bugnion's ViewModelLocator pattern.
Have a Locator class that, at construction time, registers all of your Interfaces, Implementations, AND ViewModels with your DI container.
This class should also expose each ViewModel as a get-only property, resolved out of the DI container.
In your App.xaml, add an instance of this class to a resource dictionary.
Then in any other XAML view you've got, you'll be able to just do something like DataContext={FooViewModel, Source={StaticResource Locator}}

Bang, you've 'wired up' your entire application effectively at application start. Bonus: you can now setup Design-Time implementations of your services so that the UI designer well be more useful.

LongSack posted:

This looks interesting, and since I haven't really started coding the view models yet, I'll look into it. I Hadn't planned on putting the view models into DI, but I can see the advantages of the above. As for the bonus, that's always been available using {d:DesignInstance Type=FooViewModel, IsDesignTimeCreatable=False}, hasn't it?