Decrease security restrictions in using assemblies

[Just D.]

Hi All,

Here is a problem. Our company developed a huge solution in C# using couple
third-party assemblies provided by another company. These couple assemblies
can be updated from time to time and to keep the whole solution working we
need to replace these assemblies in our solution, refresh the references to
them in our project, recompile our solution and finally send the new version
to our clients. This approach is absolutely inconvenient keeping in mind
that these updates don't change the interface and theoretically we're not
version dependent as well.

Is there any simple way to disable this extra security and use any
third-party assembly with a predefined file name located in our project
folder without recompiling the whole solution? We don't need the build
control for these external assemblies assuming that the interface is
permanent and the only one thing that changes is the build number. There are
possible improvements and bug fixes inside these third-party assemblies, but
they can be considered as a black box with the permanent interface.

I guess I explained clearly. So what is the easiest solution?

Thanks,
Just D.

 

[Gregory A. Beamer]

I guess I explained clearly. So what is the easiest solution?

Depending on how they are doing it, you can simply drop the new DLLs in the
/bin folder. I fthey are GACed, you have a bit more of an issue, of course.
Attached is a simple example.

It is also possible, in some app types and circumstances, to specify that
newer versions of the assembly are automatically accepted. Understand that
breaking interface will cause an error.

I am sure there are ways to automate the update of reference too.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Just D.]

Gregory, thanks!

I will try it now. What packager did you use to send this file in another
message?

Just D.

 

[Just D.]

Grogeory, please disregard my last message, the Total Commander did that in
one touch!

 

[Gregory A. Beamer]

Grogeory, please disregard my last message, the Total Commander did
that in one touch!

The example was just a quick example of drag and drop. I dropped two copies
of the app, then updated the dependent assembly and dropped in one folder.

If the third party component is set up like this, you should be fine. The
exception is strong typed assemblies specified in a config file (ASP.NET is
problematic for many here, as it uses full four part naming). You can drop
the other parts, but it is easier to update config. That can also be done
with an "installer".

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Just D.]

Thanks, Gregory!

I'm so sorry for typo that I made in my last message! Please accept my
apologies.

I will test everything that I have to get it working. I was sure so far that
once one of the libs is replaced the whole solution should be
updated/recompiled, but I also remember from the MS lectures that I heard
several years ago in Scottsdale that there are several different security
levels that can be configured. This is what I was searching for.

Anyway, I'll try all that out.

Just D.

 

[Gregory A. Beamer]

I will test everything that I have to get it working. I was sure so
far that once one of the libs is replaced the whole solution should be
updated/recompiled, but I also remember from the MS lectures that I
heard several years ago in Scottsdale that there are several different
security levels that can be configured. This is what I was searching
for.

For security levels, there are some settings on either the application
level or machine level that can restrict some application settings. In most
cases, it is not a case of new assemblies that is the issue, however. It is
more a case of where the assembly is located. If you have it running under
the current assembly, it is unlikely the security settings are an issue.

Good luck!

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************