funq Issue Tracker Rss Feed

Created Issue: NuGet package [2162]

richard_szalay — Wed, 12 Dec 2012 20:49:05 GMT

Any chance we could see a NuGet package for Funq? I really like to avoid committing assemblies to version control where possible.

Commented Issue: Corrupt hg repository with fix instructions [2161]

yeurch — Thu, 15 Mar 2012 12:25:30 GMT

I have no clue if Codeplex mundged this up or if something else is a problem but I wanted to give my fix steps for correcting the repository corruption I seem to be getting 100% of the time.

First is cloning this properly. Be sure to use the advanced clone option called "Use uncompressed transfer". The end result is a repo set at revision -1.

Fix #1 - revision 3
1) Clone a separate instance to revision 2. I called this funq.fixed.
2) Download the Silverlight Toolkit December 2008 from here http://silverlight.codeplex.com/releases/view/19172#DownloadId=51431.
3) Add Microsoft.Silverlight.Testing.dll and Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight.dll. to the the directory src\Lib\Silverlight UT. Commit.
4) Now the fun part. Go into the hg directory .hg\store\data\src\_lib\_silverlight _u_t\ and look for _microsoft._silverlight._testing.dll.i. Copy this to the main funq repository in the exact same location.
5) Edit .hg\store\fncache and the line data/src/Lib/Silverlight UT/Microsoft.Silverlight.Testing.dll.i (I did mine underneath the existing entry for *Testing.dll.d)
6) Update to revision 53 to prepare for fix #2

Fix #2 - Revision 54
1) Clone a copy of the fixed main repository up to revision 53 in a separate directory called funq.fixed2.
2) Update Microsoft.Silverlight.Testing.dll from the April 2010 Silverlight Toolkit in src\Lib\Silverlight UT. Commit.
3) Go into the hg directory .hg\store\data\src\_lib\_silverlight _u_t\ and this time grab both _microsoft._silverlight._testing.dll.d and _microsoft._silverlight._testing.dll.i (the only difference is the .i and .d on the end) and paste BOTH FILES back to the same location in the main repository
4) Now update to revision 54 and then to the latest revision and you should be set. I had to do this due to some file mismatches.

This only matters for those of us that wish to fix their local repository. Going forward I should be able to see any updates. If you'd like, I can send you my repository if somehow your local version is corrupt. Unfortunately I don't think codeplex can be fixed as easily but perhaps with these steps we could help them out?
Comments: Amazing fix @w0rddriven, thanks! As Arthur C. Clarke said: "Any sufficiently advanced technology is indistinguishable from magic." This desperately needs fixing in the Codeplex repo. Gets my vote.

Created Issue: Corrupt hg repository with fix instructions [2161]

w0rddriven — Mon, 08 Aug 2011 15:53:46 GMT

Created Feature: IContainer [2160]

dcazzulino — Sat, 02 Oct 2010 05:38:42 GMT

Can we have an interface to all the register and resolve methods in Container.Overloads class?

Edited Feature: Add support for checking if a type is registered [2159]

dcazzulino — Sat, 02 Oct 2010 05:23:28 GMT

IsRegistered<T...>()

Created Issue: Add support for checking if a type is registered [2159]

dcazzulino — Sat, 02 Oct 2010 05:22:58 GMT

IsRegistered<T...>()

Commented Issue: Easy registration [2158]

mythz — Wed, 10 Feb 2010 18:43:33 GMT

Here's the code for "easy" component registration (feel free to rename), which is the equivalent of registering a component so that all constructor dependencies are resolved from the container via lambdas.

It is implemented as a void extension method, but for general usage it would probably make sense to return IRegistration<T>

http://pastie.org/536675
Comments: ** Comment from web user: mythz **

I've posted about this in the discussions but it may get lost so I'll re-post:

I've developed a generics/expression based AutoWire wrapper for my web service framework that lets you register 'runtime types' around Funq's generic interfaces here:
http://code.google.com/p/servicestack/source/browse/trunk/Common/ServiceStack.Common/ServiceStack.ServiceHost/ExpressionTypeFunqContainer.cs

It's built with the same spirit as Funq where all the perf cost happens during the 'registration phase'. Basically when you register a 'runtime type' it goes through and 'binds' the Funq resolver to the largest constructor and all its public properties that have registered dependencies.

It exposes the following API's allowing you to register 'runtime types':

public void RegisterTypes(params Type[] serviceTypes)
void RegisterTypes(IEnumerable<Type> serviceTypes)

At the moment it's just a wrapper class around the Funq container so I could add this functionality without modifying the existing Funq code-base.
Although if this is a useful (and right) approach I could rewrite it as an extension method or merge it into the existing code base, etc, whatever is the preferred method.
Of course it will only work in environments that support expressions.
I do have developed an equivalent Reflection-based solution for this purpose, although it is probably not best to include these slower API's as the whole point of Funq is to run fast on embedded devices :)

Commented Issue: Easy registration [2158]

mabster — Mon, 23 Nov 2009 00:39:30 GMT

Commented Issue: Easy registration [2158]

mythz — Tue, 27 Oct 2009 21:34:12 GMT

Actually this is close to what I was looking for, you should also consider a Register overload that doesn't take typed parameters, i.e. container.Register(typeof(Interface), typeof(Impl)) so we can auto register a type at runtime (on AppDomain startup).

Commented Issue: Easy registration

mabster — Fri, 10 Jul 2009 00:59:03 GMT

Yeah, I think a parameterless Register() overload would be a nice way to do this.

Commented Issue: Easy registration

dcazzulino — Tue, 07 Jul 2009 15:29:50 GMT

This could also be just an overload to Register that doesn't receive parameters...

Created Issue: Easy registration

another_dave — Tue, 07 Jul 2009 15:09:45 GMT

Closed Issue: When checking-in code, add link to the bottom of the commit message to the workitem

dcazzulino — Fri, 27 Mar 2009 04:30:23 GMT

So that it's easy to see what's been fixed when.

Commented Issue: When checking-in code, add link to the bottom of the commit message to the workitem

dcazzulino — Fri, 27 Mar 2009 04:29:36 GMT

So that it's easy to see what's been fixed when.
Comments: Fixed on changeset 14858

Created Issue: When checking-in code, add link to the bottom of the commit message to the workitem

dcazzulino — Fri, 27 Mar 2009 04:20:52 GMT

So that it's easy to see what's been fixed when.

Closed Issue: Service Key does not need ServiceType

dcazzulino — Fri, 27 Mar 2009 04:18:10 GMT

The ServiceType property/field in ServiceKey is redundant. The ServiceType is included as the return type in the FactoryType.

I have tried the change and it works and will create a patch tomorrow. This will include an update to the tests and the Performance Sample.

I've included the update source for ServiceKey.cs only. All other changes are a result of the signature change for the constructor.
Comments: Implemented!!!

Commented Issue: Service Key does not need ServiceType

dcazzulino — Fri, 27 Mar 2009 04:17:03 GMT

Closed Feature: Register Instance

dcazzulino — Fri, 27 Mar 2009 04:06:30 GMT

As per the discussion I created on this topic, it would be nice to be able to register an instance to be used when an interface is resolved.

I've checked in a patch which covers the changes.
Comments: Implemented!

Closed Issue: Lazy Resolution with Func

dcazzulino — Sun, 15 Mar 2009 04:35:04 GMT

Kzu,

In some of my classes I like to delay the loading of dependencies for as long as possible, and I do this by accepting a Func<TService> as a ctor parameter rather than an instance of TService.

I was wondering whether it would be possible to add the ability to resolve a Func<TService> from a container even when I've only registered TService. Since you know how to instantiate TService, if I ask for a Func<TService> then you should be able to hand me a function that wraps up the Func<Container, TService> I've already given you, automatically passing in "this" as the parameter.

Then this sort of thing would be possible:

interface IBar { ... }
class Foo
{
public Foo(Func<IBar> barFactory) { ... }
}

builder.Register<IBar>(c => new Bar());
builder.Register<IFoo>(c => new Foo(c.Resolve<Func<IBar>>()));

The container would resolve Func<IBar> by returning a function that resolves IBar, passing itself into "c".

Does that make sense? I really think that would be a killer feature. I don't know if other IoC containers do this.

Matt

Commented Issue: Lazy Resolution with Func

dcazzulino — Sun, 15 Mar 2009 04:33:46 GMT

Implemented as LazyResolve :))