So I'm optimizing this apps network usage. The json return looks like this:

"prop":{
"Status":"Success"
...
}

My manager insists on:

"prop": "Success"

he saw it on vs2017's package catalog. Anybody knows anything about this?

____________________________________________________________________________________________________ "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke

Good thing i don't have a license. :-D ____________________________________________________________________________________________________ "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke

:thumbsup:Good idea. PS: I just thought of the idea of having to replace all those IUnityContainer references. That is one scary thought. ____________________________________________________________________________________________________ "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke

:( Just noticed. Edit: However, It's still hard to predict the order in which the modules will be called. Edit2: If there was an IServiceRegister interface. Then we could use it to wrap the container during registration. "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke

:) That doesn't explain the absence of "Contact us" link though. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

In that setup the following code is possible:

public class DefectiveModuel : IModule
{
public DefectiveModuel(IUnityContainer container)
{
// trash the container
}
}

The setup I'm going for is more like:

public interface IModule
{
void RegisterServices(IUnityContainer container);
void Init(IUnityContainer container);
}
public class Manager
{
public void Init(IUnityContainer root)
{
// Do something with the container
Modules.Foreach(m => m.RegisterServices(root.CreateChildContainer()));
Modules.Foreach(m => m.Init(root.Wrap()));
}
}

So modules will only be able to configure there child container. However, they will be able to use the root container to access services added by other modules on child containers under root.

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

As for what I'm trying to solve. In the current setup a module can only use it's services and the services registered on the root container, So modules cannot share there services. We could pass the root container to modules so they can register there services in a single pool, but then a module can intercept another module's services. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

OK! // Registration phase 1. Manager creates a container and registers modules. 2. Manager passes a child container to every module to registers it's services. 3. Module1 register LegitLogger as ILogger. // Resolution 4. Manager passes root container to every module to able to find services added by other modules (on child containers). Without IServiceLocator wrap, Module2 can register DummyLogger as ILoger on the root container so that LegitLogger will never be found (child containers will not be searched). The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

IServiceLocator does not have a RegisterService(). So all modules will be able to use the services registered on the parent container (and child containers) without being able to block the configuration of child containers by adding services to the parent. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

I noticed my discussion posts get flagged as spam for a while. I wanted to ask 'why' and apparently there is no "Contact us" link. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

'Cause in resolution you don't want modules changing other modules services. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

I thinks that unity containers should check child containers instead of the parent container. That way, during registration after the manager registers global modules, it can pass a child container to every module to register it's services. Then resolution can then be done using the parent container after it's wrapped in an IServiceLocator. What do you think? The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

Thanks for the tip. but I'm running native to support minor tasks you can't access from .Net.

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

Nice one!

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

PInvoke IS the hard way. and i need a link to BCL (never heard of it :cool:).

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

I'm trying to generate Interop function definitions for all of the win API. If you try to do that the hard way then YOU are the pathetic one.

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

So a header tree parser will do just fine!! Thanks. (This is a side question at best, not a serious one)

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

Any source(download/online) for structured Win API reference. PS: Structured as in CODE readable.

Where do you stop after that? Finding the bug, Fixing it or reporting result?

What should i do when a junior developer comes to me saying: "There is a bug"? He knows there is a bug since the system isn't performing as it should. But, he didn't debug to find out what or where is this bug exactly. I feel like i'm doing there bugs here.