fadd Forum Rss Feed

New Post: Project moving

gedw99 — Wed, 26 Aug 2009 21:45:49 GMT

Why not simply run your own SVN server or HG server. Both are very easy to do and you get full control.

we do that and never had any issues (touch wood).

I also think HG ( Mercurial) is far superior because of the ease of doing branches and merges, and am myself thinking of moving to it.
And it is faster

New Post: Project moving

jgauffin — Mon, 08 Jun 2009 11:35:19 GMT

I'm tired of codeplex worthless subversion integration. It can't handle conflicts at all. And sometimes it says that there are no new updates (but there are).

I'm so sick of it, so I want to move the project to a new site.

My suggestions:

* Google Code

* BitHub

I'm also thinking of switching to Mercurial instead of subversion.

What do you think?

New Post: SecurityException in PluginFinder!?

jgauffin — Tue, 20 Jan 2009 08:21:45 GMT

First google result when searching for "CreateDomain FileIOPermission":

http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/313208ba-2a33-48a6-93ec-e17f6560dbe1/

Searching for plugins in the primary appdomain will load _ALL_ dlls into your application, and they will remain there during your programs lifetime.

New Post: SecurityException in PluginFinder!?

c3p0 — Tue, 20 Jan 2009 07:56:55 GMT

I changed my Find function in PluginFinder.cs as below. It works now but is probably suboptimal. If you find a better solution, please post it!

BR,
Martin

public void Find(string fullPath, IEnumerable<Type> types)
        {
            AppDomain domain = AppDomain.CreateDomain("ModuleLoader");

            string test = GetType().Assembly.Location;

       //   PluginFinder finder = (PluginFinder)domain.CreateInstanceFromAndUnwrap(
       //                                           GetType().Assembly.Location ?? string.Empty, GetType().Namespace + ".PluginFinder");

            FindInternal(fullPath, types);

          // finder.FindInternal(fullPath, types);
            Assign(this.Plugins);

            //AppDomain.Unload(domain);
        }

New Post: SecurityException in PluginFinder!?

bradels — Mon, 19 Jan 2009 21:28:43 GMT

I am having the same issue.
I think it relates to having the fadd libraries in a separate assembly to the project in which you are loading your plugins into. I have not had a chance yet to test this theory- but are you also doing the same thing?
Did you manage to resolve the issue? I will post back here if I resolve it.

New Post: SecurityException in PluginFinder!?

c3p0 — Tue, 16 Dec 2008 17:20:40 GMT

Hi!

When I run PluginManager.Start(), I get a security exception (full excption is below). Debugging shows that it originates from this line:

PluginFinder finder = (PluginFinder)domain.CreateInstanceFromAndUnwrap(GetType().Assembly.Location ?? string.Empty, GetType().Namespace + ".PluginFinder");

Any ideas about what can be source of this problem?

Full exception:

"Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."

Any ideas would be appreciated! :)

New Post: load plugin error on plugin not in default path

jgauffin — Wed, 10 Dec 2008 13:16:52 GMT

Feel free to create a patch with the changes.

New Post: load plugin error on plugin not in default path

BloodAxe — Thu, 20 Nov 2008 19:32:29 GMT

Hi! It's me with bugs in plugin manager again!

After long time i've discovered that Assembly.LoadFrom causes unexpected behavior for plugins, that contains use(reference) some class libraries that not used by application code directly.

For example:

Application Directory:

- main.exe

- foo.dll /* called in main.exe - so it loaded in AppDomain gracefuly */

- bar.dll /* there are no calls to it library in main.exe, so it assembly will not be loaded */

-/Plugins

- testPlugin.dll /* Use bar.dll, but Assembly.LoadFrom will not search for bar.dll in parent directory! */

The reason of this is next - Assembly.LoadFrom accepts assembly name, not it path. I don't know, why Assembly.LoadFrom accepts file path (Maybe, it use it like UNC path..don't know), but it works on simpe use cases. Fortunately method Assembly.LoadFile resolves all it's issues.

New Post: Again, release build fails

jgauffin — Wed, 22 Oct 2008 06:47:11 GMT

fixed. We try to wrap all tests with #if DEBUG

New Post: Again, release build fails

swallace21 — Tue, 21 Oct 2008 16:45:57 GMT

Looks like misplaced #DEBUG statements, but I can't be sure.

New Post: Release build fails

jgauffin — Mon, 22 Sep 2008 06:18:01 GMT

Fixed =)

New Post: Release build fails

BloodAxe — Thu, 18 Sep 2008 10:03:16 GMT

Another look-like error:$0In files ValidateMaxAttribute.cs and ValidateMinAttribute.cs namespace Fadd.Globalization declared in DEBUG scope, so in release it becomes inactive,and build fails.$0

New Post: load plugin error on plugin not in default path

ywscr — Wed, 17 Sep 2008 00:45:32 GMT

$0is ok,$0$0Assembly assembly = Assembly.Load(typeInfo.Location, evidence);$0$0$0change to$0$0Assembly assembly = Assembly.LoadFrom(typeInfo.Location, evidence);$0$0

New Post: load plugin error on plugin not in default path

BloodAxe — Tue, 16 Sep 2008 10:39:33 GMT

A last fix:$0In file PluginManager.cs, line 142:$0$0Change Assembly.Load call to Assembly.LoadFrom, because Assembly.Load is good only for GAC-ed or located in current directory assemblies.$0$0Assembly.LoadFrom works fine.$0$0$0

New Post: load plugin error on plugin not in default path

BloodAxe — Tue, 16 Sep 2008 09:08:25 GMT

Thanks to you. You've done a great work!

New Post: load plugin error on plugin not in default path

jgauffin — Tue, 16 Sep 2008 08:58:49 GMT

Ok, I've fixed that in the latest source code version. Thanks for taking the time and finding the bug.

New Post: load plugin error on plugin not in default path

BloodAxe — Tue, 16 Sep 2008 07:59:56 GMT

The problem is in PluginFinder.cs in line 176:$0$0 $0$0plugin = new PluginTypeInfo(assembly.FullName, type, publicKey);$0$0$0$0$0The signature of c'tor is PluginTypeInfo(string assemblyLocation, Type type, byte[] publicKey), so, first parameter expected to be an absolute path, where assembly file are located. But passed only assembly.FullName property. $0$0 $0$0$0$0$0$0

New Post: load plugin error on plugin not in default path

BloodAxe — Tue, 16 Sep 2008 07:59:56 GMT

New Post: load plugin error on plugin not in default path

ywscr — Sun, 14 Sep 2008 09:14:11 GMT

first ,thank's you work
now,program can found plugin.dll from other path,but can't load it.

error line:
LoadModules() function on PluginManager.cs

Assembly assembly = Assembly.Load(typeInfo.Location, evidence);

New Post: Release build fails

jgauffin — Fri, 12 Sep 2008 12:37:15 GMT

Fixed.