Trường hợp cho hoặc chống lại .NET (con thú) [đã đóng]


92

Công ty tôi làm việc sử dụng C ++ Builder 6. Chúng tôi đã phát triển mã gốc kể từ khi hình thành. Sản phẩm chủ lực của chúng tôi được viết hoàn toàn bằng mã gốc.

Vào .NET Framework với chuông và còi của nó. Tôi ngã, móc, câu và chìm. Tôi thuyết phục ban giám đốc rằng .NET hoàn toàn nên là khuôn khổ mới của chúng tôi cho tất cả các phát triển phần mềm mới và chúng tôi nên bắt đầu di chuyển mã hiện tại của mình càng sớm càng tốt. Với tất cả những lợi ích nó không có nhiều thuyết phục. Họ chấp nhận đề nghị của tôi như thường lệ.

Tại thời điểm này, tôi bắt đầu phát triển ứng dụng .NET đầu tiên của mình. Tất cả đều diễn ra đúng như kế hoạch. Dự án chỉ là một thành phần của sản phẩm của chúng tôi. Và vì vậy tôi bắt đầu tạo một trình cài đặt cho thành phần mới này. Là một công ty, chúng tôi tự hào về việc làm cho mọi thứ cho người dùng dễ dàng nhất có thể. Ngay cả Microsoft với hàng nghìn nhà phát triển cũng không tạo trình cài đặt như chúng tôi. Ví dụ: khi bạn cài đặt Microsoft CRM, bạn sẽ chỉ nhận được danh sách các lỗi và điều kiện tiên quyết cần cài đặt trước khi bạn có thể tiếp tục. Không phải chúng tôi. Không bao giờ. Nếu bạn cần một cái gì đó, chúng tôi sẽ cài đặt nó cho bạn.

Điều này làm cho cài đặt của chúng tôi cảm thấy rất dễ dàng. .NET Framework chưa được cài đặt? Không vấn đề gì! Chúng tôi sẽ làm điều đó cho bạn. Cần máy khách SQL Native? Khỏe!

Vấn đề là ở chỗ, hiện tại một thành phần duy nhất của giải pháp của chúng tôi được viết bằng .NET, nó làm phức tạp quá trình cài đặt một cách đáng kinh ngạc. Trước khi tôi có thể cài đặt sản phẩm của chúng tôi, tôi cần thực hiện những việc sau:

  • Phát hiện xem điều kiện tiên quyết đã được cài đặt hay chưa

  • Cài đặt nó nếu nó không

  • Xác minh rằng nó đã được cài đặt thành công

  • Điều kiện tiên quyết tiếp theo

Để cài đặt .NET Framework, trước tiên tôi cần có Windows Installer 4.5. Nhưng có các phiên bản khác nhau cho các hệ điều hành khác nhau, vì vậy tôi thêm tính năng phát hiện hệ điều hành và khởi chạy EXE chính xác. Ồ, .NET framework đã được đóng gói sẵn với 2k8 và exe của trình cài đặt không thể chạy trên nó, bạn phải chạy OCSetup.exe với các tham số để cài đặt nó.

Và vì vậy nó tiếp tục. Sau đó, SQL Express 2005 cần được cài đặt. Các phụ thuộc lại tăng lên một lần nữa.

Tôi tranh luận với ban quản lý rằng ngay cả Microsoft cũng không làm cho người dùng dễ dàng như vậy. Phản ứng của họ là không có lý do gì để chúng ta không giỏi hơn họ theo cách này. Tôi không thể tranh luận về điều đó ngoại trừ việc tôi cảm thấy rằng có những lý do rất tốt mà họ đã áp dụng cách tiếp cận của mình.

Đột nhiên, trình cài đặt của chúng tôi rất lớn. Tất cả các điều kiện tiên quyết cho .NET, thậm chí không nói về hỗ trợ 64 bit có một loạt EXE riêng biệt để cài đặt. Vì vậy, bây giờ nó đã đến mức mà chúng tôi muốn người dùng có thể tải xuống bản đánh giá "nhanh chóng". Thật là một câu chuyện hài hước. Bạn cần tải xuống 500MB để chạy ứng dụng 30MB. Phần lớn gói cài đặt là điều kiện tiên quyết.

Ban quản lý cảm thấy rằng chúng tôi có quá nhiều phụ thuộc / điều kiện tiên quyết. Tôi hoàn toàn hiểu. Họ gợi ý rằng chúng ta nên rời khỏi .NET framework, quay trở lại bản địa nơi mọi thứ vẫn còn "dễ dàng" về mặt cài đặt. Đây là nơi mà một phần tôi muốn ủng hộ .NET giải thích những lợi ích trong bức tranh lớn, trải nghiệm phát triển được cải thiện, bảo trì dễ dàng hơn và chất lượng mã tổng thể. Phần khác tôi hết lòng đồng ý với họ! Việc phát triển trong .NET chỉ đơn giản là yêu cầu bạn cài đặt quá nhiều điều kiện tiên quyết khác khiến quá trình cài đặt trở nên phức tạp.

Có, một số người ủng hộ .NET sẽ tuyên bố rằng mọi thứ nên được cài đặt trên hệ điều hành được vá và cập nhật. Điều này đúng, nhưng không phải tất cả khách hàng đều có điều này và chỉ cần nói "Tôi xin lỗi, hãy cập nhật trước" sẽ không cắt đứt được. Hãy nhớ rằng, chúng tôi tự hào về trải nghiệm người dùng nói chung.

Bây giờ chúng tôi đang xem xét viết lại mã gốc và tôi biết chúng tôi đang thua về tốc độ phát triển và tất cả các tính năng của .NET. Nhưng chúng tôi đang đạt được lợi nhuận trong lĩnh vực này, dù là nhỏ nếu bạn nhìn vào bức tranh lớn hay không. Vì chúng tôi có kỹ năng phát triển mã gốc và .NET thực sự là nền tảng mới đối với chúng tôi, nên việc quay trở lại cũng rất hợp lý.

Câu hỏi của tôi là: quan điểm của công ty bạn về vấn đề này là gì nếu nó thậm chí là một vấn đề và trường hợp kinh doanh sẽ như thế nào mà tôi đề xuất với ban quản lý giả sử tôi muốn tiếp tục chuyển tất cả các sản phẩm của chúng tôi sang .NET?


23
+1 cho một câu chuyện đáng yêu.
— jgauffin

25
Không có trình cài đặt sơ khai cho .net tải xuống các thành phần khi cần thiết? Việc đóng gói các trình cài đặt đầy đủ là phù hợp với bản phát hành DVD nhưng nếu họ đã tải xuống bản đánh giá, thực tế bạn có thể cho rằng họ đang trực tuyến để cài đặt trực tuyến .net.
— Rup

4
Trớ trêu thay, một số trong những cuốn sách NET Tôi đã học được trong những ngày đại học của tôi đề cập việc triển khai xcopy là một trong những lợi ích chính của nó :)
— Madhur Ahuja

25
Bạn đã quên bao gồm sự phụ thuộc của mình vào Windows. Đó là một vài gigabyte khác. Sử dụng bootstrappers.
— Hans Passant

13
Câu chuyện thú vị, phải có tiêu đề, "Làm thế nào không thay đổi như thế nào toàn bộ công ty của bạn kinh doanh dựa trên sau khi đọc một số tài liệu tiếp thị và trước khi học những gì bạn thực sự sẽ cần phải làm gì để sử dụng khuôn khổ mới đúng"
— Andrew Barber

Câu trả lời:


50

Đây là lý do tại sao nhiều công ty đã chuyển sang trình cài đặt web tải xuống tất cả các điều kiện tiên quyết ngay lập tức từ trang chủ của bạn. Vì trong hầu hết các trường hợp, hệ điều hành có 99% những gì cần thiết (nếu chúng đã được cập nhật bằng Windows Update).

Tôi sẽ không đặt mọi thứ cho x64 và x32 trong cùng một trình cài đặt. Tạo hai trình cài đặt, một trình cài đặt cho mỗi kiến ​​trúc.


2
Tôi không tin rằng bạn có thể tải các gói cài đặt x64 và x86 vào một cơ sở dữ liệu MSI duy nhất.
— David Heffernan

Thật. Tôi vừa phản hồiSuddenly, our installer is massive. All the prerequisites for .NET, not even talking about 64 bit support which has a whole seperate range of EXEs to install
— jgauffin 17/12/10

6
BẤT KỲ phần mềm nào yêu cầu trình cài đặt x86 và x64 riêng biệt! Rên rỉ ..
— abatishchev

4
abatishchev: Nếu phần mềm chỉ là một tệp nhị phân .NET được biên dịch cho kiến ​​trúc "Bất kỳ", thì sẽ không cần cài đặt x86 và x64 riêng biệt. Chỉ khi bạn phải cài đặt .NET framework thì bạn mới cần đến các trình cài đặt riêng biệt.
— Gabe

Nếu bạn viết một trình cài đặt web, xin hãy nhớ về những người sống sau proxy. Ngay cả Microsoft cũng thường không nhớ về những người sống sau ISA của chính họ (Tôi đang xem bạn cài đặt Web Developer).
— Egor Pavlikhin

39

Paint.NET kết thúc cài đặt các điều kiện tiên quyết một cách độc đáo mà không đóng gói .NET framework với nó theo mặc định. Kết quả cuối cùng là một tệp thực thi shim không được quản lý sẽ kiểm tra khung công tác .NET và một số nội dung khác và giữ bạn khi nó được cài đặt; tất cả được tải xuống khi cần thiết. Sau đó, họ chạy một ứng dụng WinForms pInvokes vào MSI để gói gọn hơn quá trình cài đặt trong bông gòn.

Đáng giá một Google.

Cũng có thể là thực tế là nhiều máy khách sẽ được cài đặt một số phiên bản .NET Framework vì nó là một phần của Microsoft Update - làm cho nó dễ dàng tiêu thụ hơn trong thế giới kinh doanh.

Bài viết trên blog Paint.NET về cách cài đặt:

http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/

http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (cảm ơn Rup!)

Đọc thêm một chút về câu chuyện, có lẽ ban quản lý đã phải trải qua những khó khăn khi triển khai ứng dụng C ++ ít nhất một lần, nhưng giờ nó đã được thực hiện và được xếp vào loại "dễ dàng". Dành một chút thời gian để chống lại việc triển khai và trình bày điều này với ban quản lý và giấu nhẹm nỗi đau, cho họ thấy việc cài đặt dễ dàng như thế nào :)


Cảm ơn vì liên kết. Phần thứ hai là blog.getpaint.net/2008/08/25/… (Tôi không thể thấy liên kết từ phần đầu tiên trên trang, mặc dù nó thực sự có trong tiêu đề)
— Rup

@Rup tìm thấy rất tốt! Tôi đã nhìn sơ qua và không phát hiện ra nó. Tôi sẽ sửa đổi câu trả lời của mình để hiển thị nó.
— Adam Houldsworth

Tôi tự hỏi nếu có trình cài đặt mã nguồn mở tương tự như 4.0 cho Paint.net. Nó sẽ cực kỳ hữu ích cho bất kỳ ai phân phối ứng dụng .net.
— dbkk

1
@dbkk bạn đang nói với tôi! Paint.NET từng phát hành mã cho chương trình và trình cài đặt, nhưng sau đó nó đã bị biên tập lại do các chương trình copy-cat không cấp cho tác giả.
— Adam Houldsworth

1
Nếu bạn cài đặt / cập nhật Paint.NET với Visual studio đang mở, nó có thể làm hỏng Visual Studio. Vì vậy, tôi muốn nói rằng trình cài đặt của họ vẫn cần hoạt động.
— Greg

37

Hãy quay lại lý do tại sao bạn muốn chuyển từ mã gốc sang mã .NET ngay từ đầu: nó hiệu quả hơn cho bạn, với tư cách là một lập trình viên. Nhiều thứ trong .NET dễ dàng hơn trong C ++ (hoặc bất kỳ ngôn ngữ mẹ đẻ nào bạn đang sử dụng) và vì vậy bạn có thể phát triển ứng dụng của mình nhanh hơn nhiều.

Sau đó, thời gian bạn dành để phát triển ứng dụng như thế nào so với thời gian bạn dành để phát triển trình cài đặt? Ngay cả khi bạn phải dành vài tuần để hoàn thành trình cài đặt (cụ thể là phần thiết lập khung), đó ít nhiều sẽ là thời gian duy nhất bạn phải trải qua điều đó.

Đối với tất cả các ứng dụng trong tương lai, bạn sẽ sử dụng một trình cài đặt gần như giống hệt nhau; bạn vẫn sẽ thực hiện tất cả các kiểm tra điều kiện tiên quyết, nhưng thay vì sao chép tệp vào C: \ Foo, bạn đang sao chép một số tệp khác nhau vào C: \ bar.

Theo tôi, đây là một câu hỏi kinh tế học đơn giản. Đúng vậy, việc phát triển trình cài đặt (tốt / hoàn chỉnh) cho ứng dụng .NET sẽ đắt hơn, nhưng nếu đó là bước bạn cần thực hiện một lần để cải thiện đáng kể thời gian phát triển của mình thì đó là điều không cần bàn cãi. Lợi tức đầu tư của bạn có thể sẽ diễn ra trong vài tuần.


1
+1 trải nghiệm cài đặt tốt trong .NET rất khó để ghim, nhưng như bạn nói, chỉ nên dùng một lần. Lợi ích của việc có hầu hết những thứ mà bạn sẽ cần là một Hệ thống.
— Adam Houldsworth

2
Tôi vô cùng mong đợi sự ra mắt của Wix Burn , bộ khởi động đầu tiên thực sự hoạt động (tôi hy vọng). DotNetInstaller cùng với NSIS là những gì tôi hiện đang sử dụng. Nhưng việc xử lý UAC vẫn chưa hoàn hảo.
— Uwe Keim

1
@Uwe Có vẻ như Wix Burn sẽ được phát hành cùng thời điểm với Duke Nukem Forever .
— dbkk

Điều đó sẽ rất tuyệt. Tôi đã thấy ảnh chụp màn hình xem trước của Duke Nukem Forever . Vì vậy, nó sẽ sớm có mặt ở đó ;-)
— Uwe Keim

17

Tôi cảm thấy tôi cần phải trả lời tuyên bố này:

Có, một số người ủng hộ .NET sẽ tuyên bố rằng mọi thứ nên được cài đặt trên hệ điều hành được vá và cập nhật. Điều này đúng, nhưng không phải tất cả khách hàng đều có điều này và chỉ cần nói "Tôi xin lỗi, hãy cập nhật trước" sẽ không cắt đứt được. Hãy nhớ rằng, chúng tôi tự hào về trải nghiệm người dùng nói chung.

Nếu người dùng của bạn khăng khăng muốn tự bắn vào chân mình bằng cách vận hành một hệ thống mà nhà cung cấp đã thông báo rằng họ không còn phù hợp với mục đích , thì bạn không thể làm gì nhiều để 'giúp' họ. Tôi biết rằng điều này khiến tôi trông giống như một nhà hoạt động đáng ghét, nhưng tôi nhìn nó theo cách mà một người buôn bán thủ công có thể làm - tùy thuộc vào khách hàng để đảm bảo rằng môi trường mà họ muốn tôi làm việc âm thanh và phù hợp với sản phẩm. Nếu không, tôi cũng sẽ chấp nhận nghỉ việc nhiều hơn để làm công việc đó, nhưng nó vẫn có thể khiến họ phải làm thêm vì họ chưa có tầm nhìn xa để đảm bảo rằng họ hiểu những gì họ đang mua.

Tôi tin rằng khách hàng phần mềm đã được phép không biết gì trong thời gian đủ dài và bây giờ họ cần phải hiểu họ đang mua cái gì. Vận hành một môi trường CNTT doanh nghiệp không được vá đúng cách cũng giống như việc tiếp tục chạy một chiếc xe đã bị nhà sản xuất thu hồi - gói dịch vụ Windows tương đương với việc thu hồi theo nhiều khía cạnh. Bạn không có nghĩa vụ pháp lý phải nộp đơn thu hồi, nhưng đó là lợi ích tốt nhất của bạn với tư cách là một doanh nghiệp và bạn có thể phải chịu trách nhiệm về những thiệt hại do trốn tránh trách nhiệm của mình.


2
Tôi cho rằng việc thu hồi của nhà sản xuất hơi quá đà về mặt tương tự - tôi có thể nói, nó giống như việc lái một chiếc xe có túi khí hoặc ABS trước - các tính năng mới đã đi kèm với việc cải thiện chất lượng và nâng cao thanh chất lượng. Những thứ cũ không đột nhiên trở nên hỏng hóc hoặc nguy hiểm, giờ đây nó chỉ được chấp nhận là thấp hơn mức trong tiêu chuẩn ngày nay, tôi chắc chắn rằng nhóm Windows 95 sẽ tranh luận rằng vào thời điểm họ nghĩ rằng mức này khá cao! :-) Tôi vẫn đồng ý với bạn, thiếu hiểu biết về sự tiến bộ của chất lượng không phải là một đức tính tốt.
— Adam Houldsworth

11
Tôi không đồng ý 100%. Khách hàng đã được yêu cầu phải hiểu biết quá lâu. Tại sao tôi phải biết liệu tôi đang x86 hay x64? Tại sao tôi phải biết gói dịch vụ tôi đang chạy? Hãy để tôi mua phần mềm của bạn và bạn tìm ra những gì cần xảy ra để nó chạy. Phần mềm tiêu dùng đang hướng tới mô hình iOS / Android / AppStore một cách chắc chắn và bất kỳ nhà phát triển nào yêu cầu người dùng biết bất kỳ điều gì khác ngoài những chi tiết cơ bản nhất về thiết bị của họ sẽ bị bỏ lại phía sau.
— kubi

1
@kubi tất nhiên, tương tự iOS đi kèm với giả định rằng phần cứng không thay đổi vì nó được kiểm soát bởi nhà cung cấp. PC hoàn toàn có thể được cấu hình nên cần phải có một số kiến ​​thức hoặc nhận thức về các yêu cầu - hoặc ít nhất là nhận thức về nhu cầu có người biết họ đang làm gì là cần thiết. Tôi biết kích cỡ lốp xe của mình hoặc đưa xe cho người biết tôi sẽ thay lốp xe.
— Adam Houldsworth

3
@kubi: Tôi đồng ý với bạn về mô hình người dùng bình thường - sự khác biệt ở đây là không có lý do gì để người dùng không ủy quyền tất cả các vấn đề kỹ thuật như phiên bản nền tảng cho tôi) nhà sản xuất hoặc tôi, với tư cách là nhà phát triển. Do đó chúng không phải là một vấn đề. Người dùng gặp vấn đề là người dùng doanh nghiệp, những người không nhất thiết phải có tiếng nói về cấu hình của họ và những người cần phải có nhà cung cấp CNTT có thẩm quyền trả tiền để giải quyết những vấn đề này.
— Tom W

4
Tuy nhiên, người dùng không quan tâm đến bất kỳ lập luận nào của chúng tôi. Họ muốn sử dụng phần mềm của bạn ... nhưng có thể từ bỏ nếu quá trình cài đặt quá khó khăn. Họ có thể ít quan tâm đó là lỗi của ai - của Microsoft, nhà cung cấp hay của chính họ.
— dbkk

7

Bất kỳ ứng dụng Visual C ++ nào cũng có điều kiện tiên quyết / phụ thuộc bên ngoài: thời gian chạy 6.0, 2003, 2005, 2008 hoặc 2010? không có SP, SP1 hoặc SP2? x86 hoặc x64? 2005 SP2 yêu cầu phiên bản Windows Installer nào? Và những gì 2008 SP1? Vân vân và vân vân.

Vì vậy, đó là những lập luận xa vời! Giống như những lời càu nhàu của Joel về .NET. Và nhìn xem bây giờ là gì !


3
+1 cho liên kết đến trang web của Joel
— Security Hound

-1 để liên kết đến trang web Joels.
— Phill

Bạn có thể liên kết tĩnh với thời gian chạy để không cần những phụ thuộc đó.
— Tony Edgecombe

1
@Tony: Liên kết tĩnh trong những năm 10 của thế kỷ 21? Absolute mauvais tấn ;)
— abatishchev

1 để liên kết đến trang web của Joel
— Shahid M Zubair

3

Tôi không thấy làm thế nào có nhiều điều kiện tiên quyết hơn đáng kể cho .net trên C ++ Builder. Bạn phàn nàn về SQL Server, nhưng bạn bỏ qua thực tế là bạn cũng phải cài đặt một số cơ sở dữ liệu với trình tạo C ++. Bạn phàn nàn về x64 so với x32, nhưng .NET không yêu cầu bất kỳ thay đổi nào .. exe giống nhau chạy trên cả hai (và tự biên dịch tối ưu cho cả hai môi trường). Điều tương tự không thể nói về C ++ Builder. Bạn có thể cần các phiên bản riêng của máy chủ SQL, nhưng một lần nữa điều đó sẽ áp dụng cho trình tạo C ++ (trừ khi bạn chỉ cài đặt x32 trên mọi thứ).

Có, có những vấn đề về phiên bản trình cài đặt mới, nhưng những thành phần đó không lớn lắm. Và bạn thực sự có thể yêu cầu trình cài đặt tải xuống và chỉ cài đặt các aprts cần thiết.

Trình tạo C ++ có lẽ dễ dàng hơn cho bạn vì bạn đã đầu tư thời gian vào việc tạo một trình cài đặt tốt. Bạn cần làm tương tự cho .NET, sau đó bạn có thể chọn dựa trên các vấn đề thực tế .. chứ không phải điều này.

Nhân tiện, lý do Microsoft chọn làm mọi thứ theo cách họ làm là nhiều người dùng, đặc biệt là người dùng doanh nghiệp, không đánh giá cao việc cài đặt mọi thứ tự động cho họ (có lẽ vì họ có một ứng dụng phụ thuộc vào phiên bản cụ thể của thư viện, và bạn đến và xóa nó bằng một phiên bản mới mà họ không thể dễ dàng gỡ cài đặt).

Những gì bạn xem là "làm cho nó dễ dàng hơn" cho những người kém hiểu biết thực sự đang làm cho mọi thứ khó khăn hơn rất nhiều đối với những người biết họ đang làm.

Đây là một ví dụ điển hình. Một điều tôi hoàn toàn coi thường là khi tôi cài đặt một ứng dụng cần SQL Server và nó cài đặt phiên bản SQL Server của chính nó, mặc dù tôi có thể đã có một số phiên bản mà nó có thể sử dụng. Dễ dàng cho người mới làm quen, tôi rất khó để thử và làm cho ứng dụng của bạn hoạt động với phiên bản duy nhất của tôi.


1

Nếu ứng dụng của bạn chạy dưới chế độ Mono, thì việc vận chuyển ứng dụng của bạn với thời gian chạy Mono có thể đỡ vất vả hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.