mvccontrib and mvccontrib.fluenthtml strong named?

[Vladan Strigo]

Hi all,

The code that I am building is strongly named/signed, and when
referencing MvcContrib and MvcContrib.FluentHtml VS brakes that
FluentHtml is not strong named and thus cannot be compiled in.

My question is...is this by design or some mistake?

If by design...how come? If by mistake...how can I fix it?




Thanks,
Vladan

[Eric Hexter]

mvccontrib is not strongly named by design.  Strong naming assemblies is a very painful process which incurs a lot of maintenance headaches for assemblies which use the assembly to deal with changes.  This gets more complex considering how often the project is released. I would recommend that compile the source and strong name the assembly if you want to go down this route.  I would hate to put this kind of maintenance headache on the majority of users which use mvccontrib that do not want the strong name.

'

[nholling]

The problem is that if you are using MVCContrib in a strongly named
project, you have no other choice then to recompile MVCContrib from
source and strongly name/sign it yourself. Then every time MVCContrib
updates their source code, you will have to grab a new copy change all
the projects you need so they are strongly named and recompile again.
Those who need strongly named assemblies will be hugely inconvenienced
by this.

It seems like either way you are going to inconvenience people.

What I don't understand is the burden being placed on non-strongly
named projects. I don't see how strongly named assemblies would
affect then to a great deal. A non-strongly named project can use
strongly named assemblies no problem. I'm not trying to be critical I
just want to understand.

-Nate

PS I just found out the assemblies were not strongly named and now I'm
dreading the huge amount of work I'm going to have to go through to
get this working and then to maintain it in the future. :-(

[Eric Hexter]

http://msdn.microsoft.com/en-us/library/xc31ft41(VS.71).aspx

You can us the linker to strongly name an assembly without recompiling it. 

I am just trying to balance the thousand of downloads we have had versus the two request to strongly name the assemblies. It is important to remember that there is not a single assembly for MVC Contrib.  There are 14 assemblies that we maintain for the project to integrate with various projects and frameworks. So strong naming one would mean we should strong the them all.  This would make me think it would be better to publish some documentation on the easiest way to let consumers of mvccontrib strongly name the assembly for their specific use.

Just so that I understand the context of what you are trying to do better.. Are you  building a product, a enterprise app, a framework or something else?  I typically expect that line of business apps would use mvccontrib and I would think that strongly naming an application assembly is an edge case.  Please help me understand what you are trying to do and we can come up with a solution that works best for everyone.  

Eric Hexter

Principal Consultant
Headspring Systems | www.HeadspringSystems.com
email: ehe...@HeadspringSystems.com
blog: Hex.LosTechies.com
-------------------------------------------------------------------------------------------------------------
Director - Austin .Net Users Group | www.ADNUG.org
Membership Mentor South Texas - INETA | www.INETA.org
Asp Insider | www.ASPInsiders.com

[nholling]

I was under the assumption that only delay signing assemblies could be
signed after the fact. I was completely unaware of the al.exe linker
which would let me sign an already built assembly.That would make my
life easier. Okay, that can be totally automated. Not such a big deal
then. :-)

When signing the MVCContrib assemblies I noticed that I had to sign
the ASP.NET MVC Futures assembly as well. This would add another
level of complication for the project that I was originally unaware
of.

I'm building a commercial product (an enterprise web app). We provide
a full API to our customers which they use to extend our platform.
Customer can install multiple instances of our application with
multiple versions on the same server. We also offer the source code to
our customers. We use the signing to ensure that customers are
running our version of the assemblies (for support purposes).

We also integrate with SharePoint which requires our assemblies be
GAC'ed.

My particular case is defiantly in the minority. I was just curious
about the decision. I didn't know of any type of added complexity
with strong naming assemblies.

I'll be automating this (with your suggestion Eric). This will make my
life way easier.

So this is now a non-issue for me.

Thank you so much for the help.

-Nate

On May 31, 10:43 am, Eric Hexter <eric.hex...@gmail.com> wrote:
> http://msdn.microsoft.com/en-us/library/xc31ft41(VS.71).aspx

> <http://msdn.microsoft.com/en-us/library/xc31ft41(VS.71).aspx>You can us the
> linker to strongly name an assembly without recompiling it.
>
> I am just trying to balance the thousand of downloads we have had versus the
> two request to strongly name the assemblies. It is important to remember
> that there is not a single assembly for MVC Contrib.  There are 14
> assemblies that we maintain for the project to integrate with various
> projects and frameworks. So strong naming one would mean we should strong
> the them all.  This would make me think it would be better to publish some
> documentation on the easiest way to let consumers of mvccontrib strongly
> name the assembly for their specific use.
>
> Just so that I understand the context of what you are trying to do better..
> Are you  building a product, a enterprise app, a framework or something
> else?  I typically expect that line of business apps would use mvccontrib
> and I would think that strongly naming an application assembly is an edge
> case.  Please help me understand what you are trying to do and we can come
> up with a solution that works best for everyone.
>
> Eric Hexter
>
> Principal Consultant
> Headspring Systems |www.HeadspringSystems.com

> email: ehex...@HeadspringSystems.com

> blog: Hex.LosTechies.com
> -------------------------------------------------------------------------------------------------------------
> Director - Austin .Net Users Group |www.ADNUG.org
> Membership Mentor South Texas - INETA |www.INETA.org
> Asp Insider |www.ASPInsiders.com
>