changes to a project

[Tim Zych]

We have a .net solution that we make frequent changes to. Must we physically
uninstall/reinstall the solution (really just the dll) every time, or can we
create some project structure that enables us to move the dll to a public
location so that the user can have access to the changes next time they open
the exe?

Thanks.

[Phill W.]

Re: changes to a project

Tim Zych wrote:

We have a .net solution that we make frequent changes to. Must we physically
uninstall/reinstall the solution (really just the dll) every time, or can we
create some project structure that enables us to move the dll to a public
location so that the user can have access to the changes next time they open
the exe?

Depending on the magnitude of each change, you could do either.

If you're only changing code /inside/ existing methods, then you can
copy the Dll into the application directory and it the program will pick
up the revised code when it runs.

If you add completely new methods, the same will /probably/ work.

If you change existing method signatures (changing the arguments), then
you really /ought/ to create a new "version" of the dll and rebuild the
client application to use the new library.

If you want your dll separate from your application(s), either
(a) add it to the Global Assembly Cache on the target machine - this
makes it available machine-wide, or
(b) look at the "dependentAssem bly" and "codeBase" attributes that you
can specify in App.Config - and yes, [in VB'2003], relative paths /do/
work.

HTH,
Phill W.

[Tim Zych]

Re: changes to a project

Thanks.

"Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kwrote in message
news:f0sij7$gaa $1@south.jnrs.j a.net...

Tim Zych wrote:
>

>We have a .net solution that we make frequent changes to. Must we
>physically uninstall/reinstall the solution (really just the dll) every
>time, or can we create some project structure that enables us to move the
>dll to a public location so that the user can have access to the changes
>next time they open the exe?

>
Depending on the magnitude of each change, you could do either.
>
If you're only changing code /inside/ existing methods, then you can copy
the Dll into the application directory and it the program will pick up the
revised code when it runs.
>
If you add completely new methods, the same will /probably/ work.
>
If you change existing method signatures (changing the arguments), then
you really /ought/ to create a new "version" of the dll and rebuild the
client application to use the new library.
>
If you want your dll separate from your application(s), either
(a) add it to the Global Assembly Cache on the target machine - this makes
it available machine-wide, or
(b) look at the "dependentAssem bly" and "codeBase" attributes that you can
specify in App.Config - and yes, [in VB'2003], relative paths /do/ work.
>
HTH,
Phill W.

[RobinS]

Re: changes to a project

You could deploy your application using ClickOnce deployment, and have the
user run it from the server, where it would always be up-to-date, or have
it install on the user machine and check for updates. It only updates the
changed files, not everything.

Robin S.
-------------------------
"Tim Zych" <tzy---ch@NOSp@mE@RTHL INKDOTNETwrote in message
news:eAWYQK1hHH A.4880@TK2MSFTN GP04.phx.gbl...

We have a .net solution that we make frequent changes to. Must we
physically uninstall/reinstall the solution (really just the dll) every
time, or can we create some project structure that enables us to move the
dll to a public location so that the user can have access to the changes
next time they open the exe?
>
Thanks.
>
>