H
hav
Hello all.
I actually lost my job over being unable to get an add-in to deploy,
and the reasons for this were as follows:
- I was new to .Net
- I was new to add-ins
- I was new to VB
However I do have experience using MFC/C++, but had been using Java
over the last 5 years. So, I learned all I needed to about .Net add-
ins in a month, and got the thing working on the dev machine. It even
worked on other machines at the office. But still it would not "add
in" at Telecom NZ, and I was in Australia. I asked for help. "You
are the programmer, you work it out"....even though my bosses wrote
the thing and spent a week trying to get it to deploy before I started
there. Then, "In the real world nobody deploys over a network" said
my boss....in hindsight, I should have followed that lead. I do not
mean to sound like its not my fault - I was not fast enough, and have
to live with my mistakes. But I did live, and learn....so perhaps I
can help out some of you guys, many of you ask similar questions: "My
addin works on the dev machine, what is going on?"
So, what was the problem? CAS. What is CAS?> Read on....
Customers really want the s/w they own to be safe for them to run
(especially huge telcos)! A lot of s/w is deployed over the web these
days. Although I was sending CD's, so it did not even occur to me
that Windows security designed for "Clickonce" and other web based
deployment tech was stopping my add-in from working.
My addin did install, [going to Help-About in Word or any other method
indicated that it was there] ...but it would not run. I found this
out by setting up a VMWare image with only XP, the PIA's, Office, .Net
1.1 and .Net 2. To avoid confusion with Java, I call the NET runtime
the CLR (Common lang runtime). This emulated the Telecom machines,
and lo and behold it did not work. I spent too long on testing/re-
testing every dependency from service packs for Office to different
VSTO runtimes. I did gloss over some references to CAS but was told
to focus on the problem - deployment, not a seemingly unrelated
security technology.
Office docs can have scripting macros. Outlook is a hotbed for
viruses. CAS tries to address this by distrusting "unknown"
vendor(like you and me, trying to break into the market with a new
product) software.
Result: our addins do not work. What to do? CAS provides security at
RUNTIME - this is why the addin installs and is recognised.
The CLR cannot deal with the actions of unmanaged code, like COM
objects, and Office is built on COM. For backwards compatability, it
probably always will be since its such a monster. This is sad,
because .Net is a good technology. So we are dealing with COM Interop
(even if you use VSTO).
You can probably find out about CAS yourself - this article is really
just to raise awareness of a problem that can be quite insidious
during deployment. However, in brief, CAS automatically denies
privileges to the add-in. Unmanaged code uses COM objects such as
Microsft.Interop.Office.Word (which you would have references to in
the GAC) which deal directly with the Win32 library (see Petzold if
you need to read up on this) - as opposed to going through the CLR,
like a good little object.
CAS allows the network admin to specify the privileges that every
managed code assembly (ie addin for Outlook) has, based on the degree
of trust placed in the assembly. When managed code makes a call at
runtime to access a protected OS resource, as many add-ins do, .Net
runtime checks to see whether the admin granted privileges
specifically for our addin assembly. The CLR uses a stack of pointers
to assemblies, each corresponding to a set of corresponding grants -
these are permissions.
Finally, permissions can be set in the admininstrator/SA/target user's
security policy at 3 levels: Enterprise, Machine or User. Make sure
that the SA does not allow your add-in to work at, say, Enterprise
level but deny it at the User level. The lower level settings can only
tighten restrictions, not loosen them - this is worth telling the SA
if he or she does not know this. The whole problem IS a problem,
because organisations that are large would NEVER loosen security for a
3rd party add-in...would they? I am interested in what your
experiences are in the area: how much can an installer do here? Can
it prompt that SA to loosen restrictions? I have not tested this out,
but if anyone can give me some killer information, maybe I can get my
job back...so long as my replacement doesn't read this article! ;-)
Hope this helps, and feel free to correct me if I am wrong about
something. I'd like to acknowledge David S. Platt, who's Microsoft
Press book on .Net is unafraid of pointing out the fallacies of their
tech. Also, the people at Google Group - especially Cindy Meister in
Switzerland, for their valuable help while I was working on add-ins
deployment. I am sure that if I had asked more questions I would still
be working!
Regards,
Henry Venn
I actually lost my job over being unable to get an add-in to deploy,
and the reasons for this were as follows:
- I was new to .Net
- I was new to add-ins
- I was new to VB
However I do have experience using MFC/C++, but had been using Java
over the last 5 years. So, I learned all I needed to about .Net add-
ins in a month, and got the thing working on the dev machine. It even
worked on other machines at the office. But still it would not "add
in" at Telecom NZ, and I was in Australia. I asked for help. "You
are the programmer, you work it out"....even though my bosses wrote
the thing and spent a week trying to get it to deploy before I started
there. Then, "In the real world nobody deploys over a network" said
my boss....in hindsight, I should have followed that lead. I do not
mean to sound like its not my fault - I was not fast enough, and have
to live with my mistakes. But I did live, and learn....so perhaps I
can help out some of you guys, many of you ask similar questions: "My
addin works on the dev machine, what is going on?"
So, what was the problem? CAS. What is CAS?> Read on....
Customers really want the s/w they own to be safe for them to run
(especially huge telcos)! A lot of s/w is deployed over the web these
days. Although I was sending CD's, so it did not even occur to me
that Windows security designed for "Clickonce" and other web based
deployment tech was stopping my add-in from working.
My addin did install, [going to Help-About in Word or any other method
indicated that it was there] ...but it would not run. I found this
out by setting up a VMWare image with only XP, the PIA's, Office, .Net
1.1 and .Net 2. To avoid confusion with Java, I call the NET runtime
the CLR (Common lang runtime). This emulated the Telecom machines,
and lo and behold it did not work. I spent too long on testing/re-
testing every dependency from service packs for Office to different
VSTO runtimes. I did gloss over some references to CAS but was told
to focus on the problem - deployment, not a seemingly unrelated
security technology.
Office docs can have scripting macros. Outlook is a hotbed for
viruses. CAS tries to address this by distrusting "unknown"
vendor(like you and me, trying to break into the market with a new
product) software.
Result: our addins do not work. What to do? CAS provides security at
RUNTIME - this is why the addin installs and is recognised.
The CLR cannot deal with the actions of unmanaged code, like COM
objects, and Office is built on COM. For backwards compatability, it
probably always will be since its such a monster. This is sad,
because .Net is a good technology. So we are dealing with COM Interop
(even if you use VSTO).
You can probably find out about CAS yourself - this article is really
just to raise awareness of a problem that can be quite insidious
during deployment. However, in brief, CAS automatically denies
privileges to the add-in. Unmanaged code uses COM objects such as
Microsft.Interop.Office.Word (which you would have references to in
the GAC) which deal directly with the Win32 library (see Petzold if
you need to read up on this) - as opposed to going through the CLR,
like a good little object.
CAS allows the network admin to specify the privileges that every
managed code assembly (ie addin for Outlook) has, based on the degree
of trust placed in the assembly. When managed code makes a call at
runtime to access a protected OS resource, as many add-ins do, .Net
runtime checks to see whether the admin granted privileges
specifically for our addin assembly. The CLR uses a stack of pointers
to assemblies, each corresponding to a set of corresponding grants -
these are permissions.
Finally, permissions can be set in the admininstrator/SA/target user's
security policy at 3 levels: Enterprise, Machine or User. Make sure
that the SA does not allow your add-in to work at, say, Enterprise
level but deny it at the User level. The lower level settings can only
tighten restrictions, not loosen them - this is worth telling the SA
if he or she does not know this. The whole problem IS a problem,
because organisations that are large would NEVER loosen security for a
3rd party add-in...would they? I am interested in what your
experiences are in the area: how much can an installer do here? Can
it prompt that SA to loosen restrictions? I have not tested this out,
but if anyone can give me some killer information, maybe I can get my
job back...so long as my replacement doesn't read this article! ;-)
Hope this helps, and feel free to correct me if I am wrong about
something. I'd like to acknowledge David S. Platt, who's Microsoft
Press book on .Net is unafraid of pointing out the fallacies of their
tech. Also, the people at Google Group - especially Cindy Meister in
Switzerland, for their valuable help while I was working on add-ins
deployment. I am sure that if I had asked more questions I would still
be working!
Regards,
Henry Venn