changes to a project

  • Thread starter Thread starter Tim Zych
  • Start date Start date
T

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.
 
Tim said:
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?
Click to expand...

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 "dependentAssembly" and "codeBase" attributes that you
can specify in App.Config - and yes, [in VB'2003], relative paths /do/
work.

HTH,
Phill W.
 
Thanks.

Phill W. said:
Tim said:
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?
Click to expand...

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 "dependentAssembly" and "codeBase" attributes that you can
specify in App.Config - and yes, [in VB'2003], relative paths /do/ work.

HTH,
Phill W.
Click to expand...
 
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.
 
Back
Top