.NET (짐승)에 대한 또는 반대 사례 [종료 됨]

제가 일하는 회사는 C ++ Builder 6을 사용하고 있습니다. 우리는 개념부터 네이티브 코드를 개발해 왔습니다. 우리의 주력 제품은 완전히 네이티브 코드로 작성되었습니다.

종소리와 휘파람으로 .NET Framework에 들어갑니다. 나는 넘어지고, 훅, 라인과 싱커. 저는 .NET이 모든 새로운 소프트웨어 개발을위한 새로운 프레임 워크가되어야하며 기존 코드 라인을 최대한 빨리 마이그레이션해야한다고 경영진을 설득합니다. 모든 이점으로 인해 많은 설득력이 필요하지 않습니다. 그들은 평소처럼 내 제안을 받아들입니다.

이 시점에서 저는 첫 번째 .NET 애플리케이션 개발을 시작합니다. 모든 것이 계획대로 진행되고 있습니다. 이 프로젝트는 우리 제품의 한 구성 요소 일뿐입니다. 그래서 저는이 새로운 구성 요소에 대한 설치 프로그램을 만드는 시점에 도달했습니다. 회사로서 우리는 사용자를 위해 가능한 한 쉽게 일을 만드는 것에 자부심을 느낍니다. 수천 명의 개발자가있는 Microsoft조차도 우리처럼 설치 프로그램을 만들지 않습니다. 예를 들어 Microsoft CRM을 설치하면 계속하기 전에 설치해야하는 오류 및 필수 구성 요소 목록 만 받게됩니다. 우리가 아닙니다. 못. 필요한 것이 있으면 설치해드립니다.

이것은 우리의 설치를 매우 쉽게 만듭니다. .NET Framework가 설치되어 있지 않습니까? 문제 없어요! 우리는 당신을 위해 그것을 할 것입니다. SQL 네이티브 클라이언트가 필요하십니까? 좋아!

문제는 솔루션의 단일 구성 요소가 .NET으로 작성 되었기 때문에 설치 프로세스를 엄청나게 복잡하게 만든다는 것입니다. 제품을 설치하기 전에 다음을 수행해야합니다.

• 필수 구성 요소가 설치되었는지 감지

• 그렇지 않은 경우 설치

• 성공적으로 설치되었는지 확인

• 다음 전제 조건

.NET Framework를 설치하려면 먼저 Windows Installer 4.5가 필요합니다. 그러나 OS마다 다른 버전이 있으므로 OS 감지를 추가하고 올바른 EXE를 시작합니다. 오, .NET 프레임 워크는 이미 2k8로 패키지되어 있으며 설치 프로그램 exe를 실행할 수 없습니다. 설치하려면 매개 변수와 함께 OCSetup.exe를 실행해야합니다.

그리고 그것은 계속됩니다. 그런 다음 SQL Express 2005를 설치해야합니다. 종속성이 다시 한 번 증가합니다.

나는 마이크로 소프트조차도 사용자를 위해 이렇게 쉽게 만들지 않는다고 경영진과 주장한다. 그들의 반응은 우리가 이런 식으로 그들보다 나아지지 않을 이유가 없다는 것입니다. 나는 그들이 그들의 접근 방식을 따라 간 아주 좋은 이유가 있다고 생각한다는 것을 제외하고는 그것에 대해 논쟁 할 수 없습니다.

갑자기 설치 프로그램이 엄청납니다. .NET의 모든 전제 조건은 설치해야 할 EXE의 전체 범위를 포함하는 64 비트 지원에 대해서도 언급하지 않습니다. 이제 사용자가 "빠른"평가판을 다운로드 할 수있는 지점에 도달했습니다. 좋은 농담 이었어. 30MB 애플리케이션을 실행하려면 500MB를 다운로드해야합니다. 대부분의 설치 패키지는 전제 조건입니다.

경영진은 의존성 / 전제 조건이 너무 많다고 느낍니다. 나는 완전히 이해합니다. 그들은 우리가 .NET 프레임 워크에서 벗어나 설치 측면에서 여전히 "쉬운"땅으로 돌아갈 것을 제안합니다. 여기에서 저의 한 부분은 큰 그림의 이점, 향상된 개발 경험, 더 쉬운 유지 관리 및 전반적인 코드 품질을 설명하면서 .NET을지지하고 싶어합니다. 나의 다른 부분은 진심으로 동의합니다! .NET에서 개발하려면 설치를 복잡하게 만드는 다른 필수 구성 요소를 너무 많이 설치해야합니다.

예, 일부 .NET 지지자들은 모든 것이 패치되고 업데이트 된 운영 체제에 설치되어야한다고 주장 할 것입니다. 이것은 사실이지만 모든 고객이 이것을 가지고있는 것은 아니며 단순히 "미안합니다. 먼저 업데이트"라고 말하는 것만으로는 충분하지 않습니다. 우리는 전반적인 사용자 경험에 자부심을 느낍니다.

우리는 이제 네이티브 코드 작성을 다시 고려하고 있으며 개발 속도와 .NET의 모든 장점 측면에서 잃고 있다는 것을 알고 있습니다. 하지만 큰 그림을 보든 안 보든 작든이 영역에서 우리는 얻고 있습니다. 우리는 네이티브 코드 개발 기술을 가지고 있고 .NET이 실제로 우리에게 새로운 기반이 되었기 때문에 되돌아가는 것도 의미가 있습니다.

내 질문은 이것이다 : 만약 그것이 전혀 문제가된다면이 문제에 대한 귀사의 견해는 무엇이며, 모든 제품을 .NET으로 계속 마이그레이션하고 싶다고 가정 할 때 경영진에게 제안하는 비즈니스 사례는 어떤 모습일까요?

이것이 많은 회사가 홈페이지에서 모든 필수 구성 요소를 즉시 다운로드하는 웹 설치 프로그램으로 전환 한 이유입니다. 대부분의 경우 OS에는 필요한 것의 99 %가 있습니다 (Windows 업데이트를 사용하여 업데이트 된 경우).

x64 및 x32에 대한 모든 것을 동일한 설치 프로그램에 넣지는 않을 것입니다. 각 아키텍처에 대해 하나씩 두 개의 설치 프로그램을 만듭니다.

Paint.NET은 기본적으로 .NET 프레임 워크를 번들로 제공하지 않고 필수 구성 요소 설치를 멋지게 래핑합니다. 최종 결과는 관리되지 않는 shim 실행 파일로 .NET 프레임 워크 및 기타 항목을 확인하고 설치 될 때 손을 잡습니다. 모두 필요에 따라 즉시 다운로드됩니다. 그런 다음 MSI로 pInvokes하는 WinForms 응용 프로그램을 실행하여 설치를 면모로 마무리합니다.

Google 가치가 있습니다.

또한 많은 클라이언트 컴퓨터에 Microsoft Update의 일부인 .NET Framework 버전이 이미 설치되어있어 비즈니스 세계에서 더 쉽게 사용할 수 있습니다.

설치에 대한 Paint.NET 블로그 게시물 :

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/ (Rup에게 감사드립니다!)

이야기를 좀 더 읽어 보면 아마도 경영진은 최소한 한 번은 C ++ 애플리케이션으로 배포의 고통을 겪어야했지만 이제는 "쉬운"것으로 분류됩니다. 배포에 대해 시간을 할애하고이를 경영진에게 제시하고 고통을 숨기고 설치가 얼마나 쉬운 지 보여주세요. :)

처음에 네이티브 코드에서 .NET 코드로 전환하려는 이유로 돌아가 보겠습니다. 프로그래머로서 더 효율적입니다. .NET에서는 C ++ (또는 사용중인 모국어)보다 많은 것이 더 쉬우므로 애플리케이션을 훨씬 빠르게 개발할 수 있습니다.

그렇다면 설치 프로그램을 개발하는 데 소요되는 시간과 비교하여 애플리케이션 개발에 소요되는 시간은 어떻습니까? 설치 프로그램 (특히 프레임 워크 설정 부분)을 결정하는 데 몇 주를 소비해야하더라도 그 과정 을 거쳐야 하는 유일한 시간은 그 정도일 것입니다.

향후 모든 응용 프로그램의 경우 거의 동일한 설치 프로그램을 사용하게됩니다. 모든 필수 구성 요소 검사를 계속 수행하지만 파일을 C : \ Foo에 복사하는 대신 일부 다른 파일을 C : \ bar에 복사합니다.

제 생각에는 이것은 경제학에 대한 간단한 질문입니다. 예, .NET 응용 프로그램을위한 (좋은 / 완전한) 설치 프로그램을 개발하는 데 더 많은 비용이 들지만 그 단계가 필요한 경우 개발 시간을 대폭 향상시키기 한 번만 당연한 일입니다. 투자 수익은 아마도 몇 주 정도일 것입니다.

이 진술에 응답해야한다고 생각합니다.

예, 일부 .NET 지지자들은 모든 것이 패치되고 업데이트 된 운영 체제에 설치되어야한다고 주장 할 것입니다. 이것은 사실이지만 모든 고객이 이것을 가지고있는 것은 아니며 단순히 "미안합니다. 먼저 업데이트"라고 말하는 것만으로는 충분하지 않습니다. 우리는 전반적인 사용자 경험에 자부심을 느낍니다.

사용자가 공급 업체가 더 이상 목적에 적합하지 않다고 알린 시스템 을 운영하여 자신의 발을 쏘는 것을 고집하는 경우 경우, '도움'을 위해 할 수있는 일이별로 없습니다. 나는 이것이 나를 불쾌한 활동가처럼 보이게 만든다는 것을 알고 있지만, 수동 상인이 할 수있는 것과 같은 방식으로 그것을 봅니다. 그들이 내가 일하기를 원하는 환경이 있는지 확인하는 것은 고객에게 달려 있습니다. 제품에 적합합니다. 그렇지 않다면, 그 일을하기 위해 더 많은 보수를받을 것입니다.하지만 그들이 구매 한 것을 이해했는지 확인할 수있는 예지력이 없기 때문에 여전히 추가 작업을 유발할 수 있습니다.

나는 소프트웨어 고객들이 충분히 오랫동안 무지한 상태로 남아 있도록 허용되었고 이제 그들이 무엇을 구매하는지 이해해야한다고 믿습니다. 제대로 패치되지 않은 기업 IT 환경을 운영하는 것은 제조업체의 리콜 대상 차량을 계속 운영하는 것과 동일합니다. Windows 서비스 팩은 여러면에서 리콜과 동일합니다. 귀하는 법적으로 리콜을 제출할 의무가 없지만 사업으로서 귀하의 최선의 이익이며 책임 회피로 인한 손해에 대해 책임을 질 수 있습니다.

모든 Visual C ++ 앱에는 런타임 6.0, 2003, 2005, 2008 또는 2010과 같은 필수 구성 요소 / 외부 종속성이 있습니다. SP, SP1 또는 SP2가 없습니까? x86 또는 x64? 2005 SP2에는 어떤 버전의 Windows Installer가 필요합니까? 그리고 2008 SP1은 무엇입니까? 기타 등등.

따라서 그것은 과장된 주장입니다! .NET에 대한 Joel의 불평 처럼 . 그리고 지금 무엇을보세요 !

C ++ Builder보다 .net에 대한 전제 조건이 훨씬 더 많이 있는지 알 수 없습니다. SQL Server에 대해 불평하지만 C ++ 빌더로 일부 데이터베이스를 설치해야한다는 사실을 무시합니다. x64 대 x32에 대해 불평하지만 .NET은 변경이 필요하지 않습니다. 동일한 exe가 둘 다에서 실행됩니다 (두 환경에 대해 최적으로 컴파일 됨). C ++ Builder에 대해서도 마찬가지입니다. 별도의 SQL 서버 버전이 필요할 수 있지만 C ++ 빌더에 적용됩니다 (모든 항목에 x32 만 설치하지 않는 한).

예, 새로운 설치 프로그램 버전 문제가 있지만 이러한 구성 요소는 그다지 크지 않습니다. 그리고 실제로 필요한 aprts 만 다운로드하여 설치하도록 설치 프로그램을 얻을 수 있습니다.

좋은 설치 프로그램을 만드는 데 이미 시간을 투자했기 때문에 C ++ 빌더가 더 쉬울 것입니다. .NET에 대해 동일한 작업을 수행해야하며 실제 문제에 따라 선택할 수 있습니다.

그건 그렇고, Microsoft가 자신이하는 방식으로 작업을 선택하는 이유는 많은 사용자, 특히 기업 사용자가 자동으로 설치하는 것을 좋아하지 않기 때문입니다 (아마도 특정 버전의 라이브러리에 의존하는 응용 프로그램이 있기 때문일 수 있습니다. 쉽게 제거 할 수없는 새 버전으로 지워 버립니다.)

지식이 부족한 사람들에게 "쉽게 만들기"라고 생각하는 것은 실제로 자신이하는 일을 아는 사람들을 위해 일을 훨씬 더 어렵게 만드는 것입니다.

여기에 좋은 예가 있습니다. 내가 절대적으로 경멸하는 한 가지는 SQL Server가 필요한 앱을 설치할 때 SQL Server의 자체 인스턴스를 설치하는 것입니다. 이미 여러 인스턴스를 사용할 수있을지라도. 초보자에게는 쉽고, 앱이 내 단일 인스턴스와 함께 작동하도록 시도하는 것은 당혹 스럽습니다.

앱이 Mono에서 실행되는 경우 Mono 런타임으로 앱을 배송하는 것이 덜 고통 스러울 수 있습니다.