Running .xll from //unc path

[aberglas]

Hello Govert,

I am having problems trying to run a ExcelDna .xll from an //unc/
path. (Excel 2010).

I am loading the addin from VBA using Application.AddIns.Add "\\...",
which ends up creating the OPENn key correctly.

However, it produces a dialog offering to copy the addin to the
microsoft addins area. I do not want this to happen so say no. (I
need to suppress this dialog somehow.)

But then it fails to load the add in at all, "InitializeIntegration"

I need this because some clever sys admins map %appdata% to a UNC
path, despite the fact that UNC has never really worked properly in
Windows. And %appdata% is a good place to install addins to
unprivileged users.

Any ideas? Have you ever got ExcelDna to work with UNC?

Thanks,

Anthony

<rant>
When adding UNC, why couldn't MS have maintained basic compatibility
by just creating a special drive, e.g. "\:\mymacine\...". Then the
vast majority of existing software would still work. As it is, they
still have not got their own cmd.exe to work properly with UNC. It is
not OK to only focus on new fashionable software.
</rant>

P.S. The flicker problem was largely resolved by
keeping .ScreenUpdateing TRUE (not false!), and not doing any .Runs
from VBA to VBA. Something odd going on inside.

[Govert van Drimmelen]

Hi Anthony,

I doubt it actually has to do with UNC paths - it is more likely because your code is loaded from a network location. You can check this by mapping the network drive to a drive letter and repeating your test. I think the outcome will be the same.

The issue has to do with the .NET CAS security for network locations.
What version of .NET are you targeting (according to the RuntimeVersion attribute in your .dna file)?

Under .NET 2.0, code from a network location is not trusted by default. You can however add some CAS settings to allow the location to be trusted. The keyword to search for in this group would be "caspol". Basically you have to set the share to full trust - check this blog entry: Using CasPol to fully trust a share [http://blogs.msdn.com/shawnfa/archive/2004/12/30/344554.aspx ].
To do so, run the following from a Visual Studio command prompt:
CasPol.exe -m -ag 1.2 -url file://MyServer/MyShare/* FullTrust
You can also make the same change using the graphical .Net 2.0 Configuration tool in the control panel.

Under .NET 4.0, the default security has changed, and I actually don't expect problems loading over the network. If this is the version you are running under, my only suggestion would be to make sure you have no extra copy of ExcelDna.Integration.dll in that directory - you should not redistribute this file separately with your add-in.

Regards,
Govert

________________________________________
From: exce...@googlegroups.com [exce...@googlegroups.com] on behalf of aberglas [aber...@gmail.com]
Sent: 04 July 2012 02:19 AM
To: Excel-DNA
Subject: [ExcelDna] Running .xll from //unc path

Hello Govert,

Thanks,

Anthony

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To post to this group, send email to exce...@googlegroups.com.
To unsubscribe from this group, send email to exceldna+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/exceldna?hl=en.

[aberglas]

Hello Govert,

You are right that it does not appear to be UNC related, mapping a
drive produces the same result.  (I had had other issues with UNC in
the installer.)  I am actually using a mapping back to the same
machine, will test a different machine later.

Tedious insertion of message boxes shows it is actually crashing in my
initialization code, with
  "System.Runtime.InteropServices.COMException Unable to create
specified ActiveX."
from
  SheetsTP =
CustomTaskPaneFactory.CreateCustomTaskPane(typeof(SheetsTaskPaneUC),
"Sheets");

What is weird is that I actually create two custom task panes, both
using exactly the same pattern (WPF inside a Forms UC), and it always
crashes on this simpler one.  I have tried swapping the order.

(This only happens in .Net 3.5, 4.0 seems to fix it.  But I cannot
rely on 4.0 being available on user's machines. Excel 2010. Your
CustomTaskPane.dna always works, any .Net version.)

I have not played with CasPol, I do not think I have struck that as an
issue yet.  But in any case I cannot do that sort of thing to a user's
machine.

Any ideas most welcome.  It all works perfectly from a local drive.

("Application.AddIns.Add FullName, CopyFile:=False" stops the "Do you
want to copy the add in" message. I have somehow made the
"InitializeIntegration" message go away, which is a bit scary.)

Anthony

On Jul 4, 5:30 pm, Govert van Drimmelen <gov...@icon.co.za> wrote:
> Hi Anthony,
>
> I doubt it actually has to do with UNC paths - it is more likely because your code is loaded from a network location. You can check this by mapping the network drive to a drive letter and repeating your test. I think the outcome will be the same.
>
> The issue has to do with the .NET CAS security for network locations.
> What version of .NET are you targeting (according to the RuntimeVersion attribute in your .dna file)?
>
> Under .NET 2.0, code from a network location is not trusted by default. You can however add some CAS settings to allow the location to be trusted. The keyword to search for in this group would be "caspol". Basically you have to set the share to full trust  - check this blog entry: Using CasPol to fully trust a share [http://blogs.msdn.com/shawnfa/archive/2004/12/30/344554.aspx].
> To do so, run the following from a Visual Studio command prompt:
>     CasPol.exe -m -ag 1.2 -url file://MyServer/MyShare/* FullTrust
> You can also make the same change using the graphical .Net 2.0 Configuration tool in the control panel.
>
> Under .NET 4.0, the default security has changed, and I actually don't expect problems loading over the network. If this is the version you are running under, my only suggestion would be to make sure you have no extra copy of ExcelDna.Integration.dll in that directory - you should not redistribute this file separately with your add-in.
>
> Regards,
> Govert
>
> ________________________________________

> From: exce...@googlegroups.com [exce...@googlegroups.com] on behalf of aberglas [aberg...@gmail.com]

[Govert van Drimmelen]

Hi Anthony,

Could the problem UserControl perhaps contain some custom controls
that are not used by the working one, hence causing it to fail?

If I understand the facts are:
1. Always works under .NET 4.
2. Always works locally.
3. Fails when loaded over the network on .NET 2.0 runtime.

Then I'd say the CAS security issues are the most likely issue.

Are there any suspicious messages when running under the debugger?

Could you activate Fusion logging (http://www.hanselman.com/blog/
BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx or
search for fuslogvw) and see if that gives any clues?

Create a third CTP that is just like the working one, check that it
works, and then modify until is looks like the simple one?

-Govert

[aberglas]

Hello Govert,

I have tried to track this down but I am chasing ghosts. Various
innocuous bits of WPF can make it crash in various ways, including
bringing Excel down.

There is obviously a memory corruption going on, the root cause can be
hard to find. My code is all managed .net or VBA, so the bug is
elsewhere. This sort of thing is frightening because it can take an
unbounded amount of time to track down, and can kill projects.
Fortunately for me it only seems to happen for .xlls loaded from UNC
paths. At least for now :(.

I had similar symptoms with VSTO, so ExcelDNA is probably innocent.
But please continue to take great care with things that could corrupt
memory.

.Net 4.0 seems to fix the problem, but it is not necessarily
available. I can test for this, and load different .dna files as
appropriate. But I already need different files for x64, so this will
mean 4 add ins. If another option becomes necessary then 8 files
would be required, or maybe have VBA code generate the correct .dna
file, which has other permission etc. problems.

One suggestion is to have RuntimeVersion= property accept a comma
separated list of versions, it picks the first that is available. Or
maybe the default should be to pick the highest. Or maybe "*" should
mean that. Etc.

An extra parameter on ExternalLibrary that said bits=64 or bits=32
would also be nice, so that we could just have one .dna file for
both. (It would only load the .dll if the bits was correct.)

Regards,

Anthony

[Govert van Drimmelen]

Hi Anthony,

As you've found, I would also expect .NET 4 to be more reliable,
particularly in complicated scenarios where you are using WPF within
the native Office applications. Since it is a free, safe and small
install that is supported on Windows XP and later, it seems a good
platform to target whenever possible. By using WPF you are already
requiring .NET 3.0 or higher (probably .NET 3.5) on top of the
ubiquitous .NET 2.0. So if it were me, I'd probably just target .NET
4.

The decision on whether to fall back to .NET 2.0 if .NET 4 is not
installed is not trivial. While in theory the Excel-DNA loader could
fall back in the way you suggest, I have decided to stay consistent
with the .NET Framework developers in making the runtime version an
explicit choice. I appreciate your suggestion of adding some
additional loading options to Excel-DNA to deal with this, and will
keep it in mind. But it has not been a common request - most people
seem to either by developing on the current versions, with code
targeting .NET 4 that would not run on the older platform, or to be
targeting the widest audience by targeting the old .NET 2.0.

Anyway, if you have reasonably simple and reproducible case that
exhibits the 'memory corruption' you describe, I'd be happy to
investigate a bit.

The 32-bit / 64-bit situation is somewhat different. The current Excel-
DNA design, whereby we integrate with Excel using the native .xll
interface, does not allow the native Excel-DNA loader any control over
the 32-bit vs. 64-bit add-in choice. This means we have separate
native code .xlls, and if the wrong 'bitness' library is loaded into
the Excel instance, no Excel-DNA code ever runs. So making a unified
add-in for the 32-bit and 64-bit cases is not possible.

Regards,
Govert

[aberglas]

Hello Govert,

My users are on many different corporate systems, with lots of
different, restrictive and often pointless Group Policies. Dealing
with IT is difficult. So installing a different version of .Net is
not something I can really depend on. (BTW. Java is much better in
this regard, it can be XCopy installed, along with the application, no
external dependencies.)

As to ExcelDna supporting multiple .Net version, I was not suggesting
that the fall back be by default, but only if some specific syntax was
used. E.g. RuntimeVersion="v4.0,v3.5". Also, .Net 3.5 is NOT the
same as 2.0, even if technically you can use the same loader to access
either. If I am using WPF or Linq, say, I need 3.5, not 2.0. It
would be helpful if you could make these checks and fail with a good
message to the user, rather than obscure .dll not found messages. As
it is I cannot even test the case of only having a .Net 2.0 available
without setting up VMs -- is it possible to run with Just .Net 2.0
classes when 3.5 is available?

I understand there would need to be a 32 bit and 64 bit .xll. But why
not use the same .dna for both. Based on a convention such as
Foo-64.xll looks for Foo.dna if Foo-64.dna is not found.

The ExternalLibrary / bits=64 or bits=32 was a different suggestion.
It means that the same source .dna file can be used for both, and just
copied, which is cleaner.

I know that there are work arounds for all these, but the would be
easy to implement and make the difference between adequate and nice,
IMHO.

It one thing to install something on your own machine. It is quite
different to install it on a non-technical, highly constrained user's
machine. This is one reason that I stick to VBA where possible.

Thanks for the offer to look at a small, clean example. But that is
the problem, change something and the bug disappears. I hate this
sort of bug!

(Incidentally, wouldn't it have been nice if MS had enabled Hybrid 64
bit C code to run in a 32 bit environments on 64 bit machines. Not so
hard, just means wasting 32 bits on every pointer, which is what
happens anyway when running 64 bit in less than 4gig. Hybrid extern
procedures would have two entry points, on for 32, another for 64
bit. This would provide a smooth migration path. But instead we get
the 64 bit DLLs in System32!!! This pain will get worse before it
gets better, there will always be some 32bit dlls that we do not have
a 64bit version of.)

Anthony