l**********n
发帖数: 8443 | |
z****e
发帖数: 54598 | |
l**********n
发帖数: 8443 | 3 我用dotnet创建了一个web application，它直接用gulp了。 |
a9
发帖数: 21638 | 4 可以，为啥不行
【在 l**********n 的大作中提到】
: 方便吗？
|
B********r
发帖数: 397 | 5 理论上讲什么都行，maven，ant，sbt，bower，npm。。。
真正试过的，msBuild有多傻逼不用我说了
【在 a9 的大作中提到】
: 可以，为啥不行
|
N********n
发帖数: 8363 | 6
有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
【在 B********r 的大作中提到】
: 理论上讲什么都行，maven，ant，sbt，bower，npm。。。
: 真正试过的，msBuild有多傻逼不用我说了
|
a9
发帖数: 21638 | 7 .net配合的是nuget
不过nuget对javascript支持不太好。我一般用nuget+bower
【在 N********n 的大作中提到】
:
: 有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
: 荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
|
l**********n
发帖数: 8443 | 8 oh.
【在 a9 的大作中提到】
: .net配合的是nuget
: 不过nuget对javascript支持不太好。我一般用nuget+bower
|
g*****g
发帖数: 34805 | 9 假定你做一个应用，使用了第三方类库A和B，A 依赖于类库C 1.0，B依赖于类库C 2.0
。1.0和2.0不兼容，Strong name怎么解决这个问题？
【在 N********n 的大作中提到】
:
: 有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
: 荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
|
N********n
发帖数: 8363 | 10
类库C的1.0和2.0做成STRONG NAME SIGNED，名字看上去都是C.DLL，但
DIGITAL SIGNATURE不一样，其实就是俩不同的GUID。然后两个C.DLL加
载到系统的GLOBAL ASM CACHE中，在GAC中只认GUID不认名字。你的应
用程序在SETTINGS.XML中指明到底用哪个。如果1.0就给1的GUID，2.0
就2的GUID。
这个和编译原理的DECOUPLE重命名思路类似。编译器做分析时遇到代码
a = w + x; ... ...; a = y - z; 也是先DECOUPLE换名为a0 = w + x;
... ...; a1 = y - z; 之后再解决怎么优化。
【在 g*****g 的大作中提到】
: 假定你做一个应用，使用了第三方类库A和B，A 依赖于类库C 1.0，B依赖于类库C 2.0
: 。1.0和2.0不兼容，Strong name怎么解决这个问题？
|
|
|
g*****g
发帖数: 34805 | 11 这东西只要一个第三方的不遵守你就挂了，看上去很美罢了。
【在 N********n 的大作中提到】
:
: 类库C的1.0和2.0做成STRONG NAME SIGNED，名字看上去都是C.DLL，但
: DIGITAL SIGNATURE不一样，其实就是俩不同的GUID。然后两个C.DLL加
: 载到系统的GLOBAL ASM CACHE中，在GAC中只认GUID不认名字。你的应
: 用程序在SETTINGS.XML中指明到底用哪个。如果1.0就给1的GUID，2.0
: 就2的GUID。
: 这个和编译原理的DECOUPLE重命名思路类似。编译器做分析时遇到代码
: a = w + x; ... ...; a = y - z; 也是先DECOUPLE换名为a0 = w + x;
: ... ...; a1 = y - z; 之后再解决怎么优化。
|
l**********n
发帖数: 8443 | 12 if an assembly depends on another assembly that is not strongly named, it
cannot be registered in the GAC. In cases where the code of the third-party
assembly is not in the programmer's possession, transforming the assembly to
be strongly named can in fact be impossible. |
g*****g
发帖数: 34805 | 13 我老人家虽然不写C#，猪走路看多了。这世界上本来就没有silver bullet。还看到一
条，这是连向下兼容都做不到呀。
By default, applications will only run with the version of the .NET
Framework used to compile it, which can cause the application to fail on
machines with newer versions of the .NET Framework installed — even when
the application would normally run properly with the newer version.
party
to
【在 l**********n 的大作中提到】
: if an assembly depends on another assembly that is not strongly named, it
: cannot be registered in the GAC. In cases where the code of the third-party
: assembly is not in the programmer's possession, transforming the assembly to
: be strongly named can in fact be impossible.
|
N********n
发帖数: 8363 | 14
对于开发.Net的来说SN属于入门级常识。这个都整不清楚的第三方也写
不出啥好类库来。
【在 g*****g 的大作中提到】
: 这东西只要一个第三方的不遵守你就挂了，看上去很美罢了。
|
N********n
发帖数: 8363 | 15
向下兼容很简单。把RUNTIME按版本拆开，1.0, 2.0, 3.0...都有各自独
立的RUNTIME。代码如果对版本不敏感系统就用最新的RUNTIME执行。如
果敏感在编译时指定具体用哪个版的RUNTIME。加载代码时系统会根据设
定选择合适的RUNTIME。简单的DIVIDE & CONQUER模块化设计。像JAVA那
样从1.0到8.0全挤在一个RUNTIME里面互相制肘属于DESIGN FLAW。
【在 g*****g 的大作中提到】
: 我老人家虽然不写C#，猪走路看多了。这世界上本来就没有silver bullet。还看到一
: 条，这是连向下兼容都做不到呀。
: By default, applications will only run with the version of the .NET
: Framework used to compile it, which can cause the application to fail on
: machines with newer versions of the .NET Framework installed — even when
: the application would normally run properly with the newer version.
:
: party
: to
|
g*****g
发帖数: 34805 | 16 你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
【在 N********n 的大作中提到】
:
: 向下兼容很简单。把RUNTIME按版本拆开，1.0, 2.0, 3.0...都有各自独
: 立的RUNTIME。代码如果对版本不敏感系统就用最新的RUNTIME执行。如
: 果敏感在编译时指定具体用哪个版的RUNTIME。加载代码时系统会根据设
: 定选择合适的RUNTIME。简单的DIVIDE & CONQUER模块化设计。像JAVA那
: 样从1.0到8.0全挤在一个RUNTIME里面互相制肘属于DESIGN FLAW。
|
T********i
发帖数: 2416 | 17 大家侧重点不同罢了。
记得当年看webcast一个烙印解释了这么做的原因之一。同样的函数。在不同的.Net版
本上实现不一样。他还举了一个例子，某个程序的解决取决于两个函数并发执行完成的
先后顺序。
结果升级到高版本性能改进，latency变了，完成次序就变了。结果就不对了。给他们
指出来你原来的代码本来就有问题。人家说，我不care！
严格的runtime绑定确实能够解决这类问题。
我的系统，从IDE到version control到management console都是自己写的。dll hell就
根本不是问题了。
.0
【在 g*****g 的大作中提到】
: 你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
: 到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
: 有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
: runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
|
N********n
发帖数: 8363 | 18
对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
【在 g*****g 的大作中提到】
: 你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
: 到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
: 有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
: runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
|
l**********n
发帖数: 8443 | 19 GAC才是问题根源，private assembly没有版本问题，java更没有问题
【在 N********n 的大作中提到】
:
: 对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
: 另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
: 加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
: 一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
: 全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
: 姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
: 茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
|
g*****g
发帖数: 34805 | 20 你丫死撑倒是一把好手。一个程序不过十兆。结果装了2小时几个 G 的 runtime才能跑
，能有几个有那耐心。你软太垃圾，只能用这种土办法，还觉得牛逼了。
【在 N********n 的大作中提到】
:
: 对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
: 另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
: 加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
: 一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
: 全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
: 姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
: 茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
|
