Community
Showing results for 
Search instead for 
Do you mean 
Reply

Plugins Don't Load / DependentDlls.xml

Accepted Solution Solved
Nickel Super Contributor
Posts: 352
Country: Canada
Accepted Solution

Plugins Don't Load / DependentDlls.xml

I've got a second plugin now that test fine on my machine but fails to load at all and gets banished to DependentDlls.xml on the client computer.

 

Any ideas what could cause that?  I know bad code can do it, but it runs fine for me on my 2012 and 2013 machines.

 

In my case, I built against v14 .DLL's and tested on both.

 

Both mine and the client are running Windows 7, 64-bit.  They have all versions of .NET installed from 2.0 onward (2.0 is what I targetted).

 

Thanks,

Len

Len Kamerman
ACT! Certified Consultant

Act E-mail Marketing Trainining Course:

http://actsoftware.training

Accepted Solutions
Solution
Accepted by topic author lkamerman
‎09-25-2015 03:20 AM
Nickel Super Contributor
Posts: 352
Country: Canada

Re: Plugins Don't Load / DependentDlls.xml

Thanks to a call with Jim this morning I was able to get this resolved.  (and thanks Vivek, the logs were the key and I needed to set the switches to 4).  The crazy thing is it wasn't anything to do with the code so much as a .NET behaviour in 4.0 that doesn't allow files to be loaded unless they are trusted.  The files ran fine on my machine, but then when I sent the file via YouSendIt.com they'd be blocked.

 

Right-click, click Unblock, click Apply and we’re back in business.

 

In case anyone is curious how I got there...

 

I found that once I bumped the switches up to 4 on a few things I got a message that included ".NET Framework does not enable CAS policy by default, so this load may be dangerous" and on Googling I found that this an issue of trying to load an assembly that is not in a trusted zone.  Usually this only impacts files on a Network if the app is not run from the same location, but as it turns out the .DLL was simply blocked after being downloaded from the Internet.

 

In the meantime, I found a switch for the config file that would allow remote assemblies to be loaded, but after figuring out what happened I took it back out.  Here’s the switch:

<loadFromRemoteSources enabled="true" />

 

Cheers,

Len

Len Kamerman
ACT! Certified Consultant

Act E-mail Marketing Trainining Course:

http://actsoftware.training

View solution in original post


All Replies
Bronze Super Contributor
Posts: 1,231
Country: USA

Re: Plugins Don't Load / DependentDlls.xml

Len,

Sometimes the issue is dumped into the ACTlog.XML file.

You will need to deleted both the ACTlog.xml and dependentDLL file then restart ACT.

Close ACT using the menu since it may only update a complete log file on normal shutdown.

 

-- Jim 

Nickel Super Contributor
Posts: 352
Country: Canada

Re: Plugins Don't Load / DependentDlls.xml

Thanks Jim - I'll check that out.

 

You are saying though that you may have to delete the ACTLog.XML file to get a plugin to load on a subsequent attempt?

 

Best,

Len

Len Kamerman
ACT! Certified Consultant

Act E-mail Marketing Trainining Course:

http://actsoftware.training
Bronze Super Contributor
Posts: 1,231
Country: USA

Re: Plugins Don't Load / DependentDlls.xml

No - the log file has nothing to do with why ACT is bypassing the plug-in.

I always deleted the log file to I know so I know I have fresh info.

 

 

I think it is cleaned every session.

ACT actually copies it to a backup on each restart.

That is why there is an ACTlog2.XML file

 

Deleting the logs is an old habit I guess.

 

-- Jim 

Nickel Super Contributor
Posts: 352
Country: Canada

Re: Plugins Don't Load / DependentDlls.xml

Gotcha, thanks Jim!

 

Len

Len Kamerman
ACT! Certified Consultant

Act E-mail Marketing Trainining Course:

http://actsoftware.training
Bronze Elite Contributor
Posts: 2,115
Country: United_Kingdom

Re: Plugins Don't Load / DependentDlls.xml

Len,

 

Remember to also set your sageact.exe.config diagnostics switches to verbose (=4), since they might also give you an idea at which point your plugin is failing.

Vivek Gargav
Caldere Associates Ltd.
www.caldere.com
vgargav@caldere.com
My Blog
Nickel Super Contributor
Posts: 352
Country: Canada

Re: Plugins Don't Load / DependentDlls.xml

That switch will impact the ACTLOG.XML files, right?

 

I'm going to lose my mind... I've even given them an older plugin I wrote a long time ago that works fine for me everywhere, even in 2013 and it always ends up in DependentDlls.xml

 

I'll change the switch and see if that helps - nothing has loaded in the logs so far otherwise.

 

I've even pulled everything out of my code except the Plugin interface stuff, just enough so that it pops up a message box to show the plugin has loaded, and reference nothing other than Act.UI.dll, trying .NET 2.0 and 3.5 with v14 DLL's and.NET 4.0 with v15 DLL's

 

I'll send a $100 Omaha Steaks gift card to the first person to help me lick this problem (or something equivalent if you're outside of the USA and Canada)

 

Cheers,

Len

Len Kamerman
ACT! Certified Consultant

Act E-mail Marketing Trainining Course:

http://actsoftware.training
Bronze Super Contributor
Posts: 1,231
Country: USA

Re: Plugins Don't Load / DependentDlls.xml

Call me in the AM at +1 973 625 1119

 

You can put the $100 toward our bar bill at Perfecting ACT!

 

-- Jim

Nickel Super Contributor
Posts: 352
Country: Canada

Re: Plugins Don't Load / DependentDlls.xml

Super - I'm out first thing but I'll try you later in the day.

 

I don't have access to the machines in question - should I get them to change the logging first and get that back, or you think this is solvable without that?

 

Thanks,

Len

Len Kamerman
ACT! Certified Consultant

Act E-mail Marketing Trainining Course:

http://actsoftware.training
Solution
Accepted by topic author lkamerman
‎09-25-2015 03:20 AM
Nickel Super Contributor
Posts: 352
Country: Canada

Re: Plugins Don't Load / DependentDlls.xml

Thanks to a call with Jim this morning I was able to get this resolved.  (and thanks Vivek, the logs were the key and I needed to set the switches to 4).  The crazy thing is it wasn't anything to do with the code so much as a .NET behaviour in 4.0 that doesn't allow files to be loaded unless they are trusted.  The files ran fine on my machine, but then when I sent the file via YouSendIt.com they'd be blocked.

 

Right-click, click Unblock, click Apply and we’re back in business.

 

In case anyone is curious how I got there...

 

I found that once I bumped the switches up to 4 on a few things I got a message that included ".NET Framework does not enable CAS policy by default, so this load may be dangerous" and on Googling I found that this an issue of trying to load an assembly that is not in a trusted zone.  Usually this only impacts files on a Network if the app is not run from the same location, but as it turns out the .DLL was simply blocked after being downloaded from the Internet.

 

In the meantime, I found a switch for the config file that would allow remote assemblies to be loaded, but after figuring out what happened I took it back out.  Here’s the switch:

<loadFromRemoteSources enabled="true" />

 

Cheers,

Len

Len Kamerman
ACT! Certified Consultant

Act E-mail Marketing Trainining Course:

http://actsoftware.training