Compile to GAC from VS

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Alexander Mueller - 24 Feb 2006 15:37 GMT

Hi

we have Word-Template project in VSTO that will be used intensively
by the customer so we decided to put it to the GAC, because this also
solves privilege- and location-problems for doc-files that are saved
to an arbitary location.
I am not very familiar with NET-GAC concept, but found out
that creating a Strong Name with sn.exe and then putting the
assembly into the GAC using gacutil is all that seems to be done,
however once the assembly is registered to the GAC, i get trouble
starting a newer compiled versions of the VS-project from the
REALESE-folder. The dot-file then seems to favor the
old GAC-assembly rather then the new RELASE-assembly also it they both
share the same location; so code-changes are not executed under
these circumstances.
In order to fix this problem, i thought one might compile the assembly
to the GAC from Viual Studio directly, but i wonder how this can be
achieved/configured, without using tools like 'gacutil.exe' manually
after building. Hope the problem is reproducable.

Btw VS 2005 + VSTO 2005 + OFF 2003

Thanks for your help,
Alex

Reply to this Message

Michael Höhne - 24 Feb 2006 15:56 GMT

I ran into that problem several times. If you do not update the version
number of your assembly, the .NET framework uses a cached assembly in your
C:\Document and Settings\<username>\Lokale Settings\Application
Data\assembly folder. It will be stored somewhere beneath a DL2 or DL3
folder. I placed a simple batch into that folder, removing all assemblies in
there.

@echo off
@prompt $g
del *.dll /s /q
pause

Whenever I have the problems you mentioned, I click it and all assemblies
are gone and you're working with your current implementation. You can add
the batch file to a custom build script to automate this process.

Signature

Michael

http://www.stunnware.com/crm

----------------------------------------------------------

> Hi
>
[quoted text clipped - 20 lines]
> Thanks for your help,
> Alex

Reply to this Message

Alexander Mueller - 27 Feb 2006 09:29 GMT

Michael Höhne schrieb:

> I ran into that problem several times. If you do not update the version
> number of your assembly, the .NET framework uses a cached assembly in your
[quoted text clipped - 11 lines]
> are gone and you're working with your current implementation. You can add
> the batch file to a custom build script to automate this process.

Hi Michael,

thanks very much for your response. It didn't even know this folder
exists. As you proposed, removing the cached dlls actually solves
the problem. Btw, I have no idea how to create a custom built script.
Could you point out, where to integrate a script into the project,
is it under <project-options>-<compile>-<build events>?

Mfg,
Alex

Reply to this Message

Wamiq Ansari - 27 Feb 2006 09:50 GMT

Hi,

Most of Microsoft Solutions involving Office 2003 use 'Shadow Copying'
(C:\Docuemnt settings\<username>\........). Could I suggest using .NET
Security Policy (CASPOL) to avoid GACing your dlls. I think I use CASPOL and
have never have to delete my Shadow Copy folder to read latest build. The
following might be useful for Office Solution development:
http://msdn2.microsoft.com/en-us/library/zcfbd2sk.aspx

Best regards,

Wamiq
wamiq@msn.com

> Michael Höhne schrieb:
>
[quoted text clipped - 24 lines]
> Mfg,
> Alex

Reply to this Message

Compile to GAC from VS

Free Magazines