K works..

1. 문자열의 선언
   string str = "마음소프트";
   System.String str = "마음소프트";
   String str = "마음소프트";
   // 보통 첫번째인 string형으로 많이 선언하게 됩니다.
    
2. 인덱스(Index)로 접근하기
   string str = "가나다라마바사";
   Response.Write( str[0] );
   // 결과는 첫번째 문자인 '가' 출력
    
3. 문자열 추가
   string str1 = "반갑습니다. ";
   str1 = str1.Insert(str1.Length, "홍길동님");
   str1 = str1.Insert(0, "앗! ");
   Response.Write( str1 );
   // 결과는 '앗! 반갑습니다. 홍길동님' 출력

   string str2 = String.Concat("마", "음", "소", "프", "트");
   Response.Write( str2 );
   // 결과는 '마음소프트' 출력

   string str3 = "마" + "음" + "소" + "프" + "트";
   Response.Write( str3 );
   // 결과는 '마음소프트' 출력
    

4. 대소문자 변환
   C#은 대소문자를 구분하기 때문에 자주 사용되며, 대소문자가 구분없는 한글은 별다른 소용이 없습니다.
   예를 들면, 'MaumSoft' 값과 'maumsoft' 라는 값은 서로 틀린 값이라고 보시면 되겠습니다. 사실은 같은 값이지만 --;

   string str = "MaumSoft";
   Response.Write( str.ToUpper() );
   Response.Write( str.ToLower() );
   // 결과는 각각 'MAUMSOFT', 'maumsoft' 출력
    

5. 공백 문자열 지우기
   string str = " 마음소프트 ";
   str = str.TrimStart(); // 앞(왼쪽)쪽 문자열 삭제
   str = str.TrimEnd(); // 뒤(오른쪽)쪽 문자열 삭제
   str = str.Trim(); // 양쪽 문자열 삭제
   // 특별한 상황이 아니면, 보통 Trim을 씁니다.
    
6. 문자열을 찾아서 문자열 자르기
   전체 문자열에서 어떤 문자열을 찾아서, 그 검색된 문자열을 다음 공백까지 잘라내는 작업을 많이 합니다.
   전문 용어로 이를 파싱(Parsing)이라고 부릅니다.
   IndexOf( "검색할 문자열" );
   LastIndexOf( "검색할 문자열" );
   Substring( 자를 위치 첨자 );
   Substring( 자를 위치 첨자, 첨자에서 자를 만큼의 길이 );
    
7. 구분자 기준으로 문자열 자르기 (Split)
   구분자를 기준으로 문자열을 분리시켜서 배열로 반환합니다.
   string str = "가,나,다,라,마";
   string [] result = str.Split(',');
    
8. 문자열 치환하기
   문자열 중 특정 문자를 다른 문자로 바꾸고 싶을때 Replace 가 사용됩니다. 특히 ASP.NET 에서 내용을 보여줄때 꼭 쓰입니다.
   string str = "마음소프트\r\nC# 라이브러리";
   str = str.Replace( "\r\n", "<br>" );
   // 글 입력을 받을 때 textarea 내에서 엔터를 치면 /r/n 으로 데이터가 입력됩니다. (일명 Carriage return 과 New line)
   // 그냥 출력해서 보여주면 내용이 라인 구분없이 계속 붙어 나옵니다.
    

1. System.String 클래스의 인스턴스 메서드
   

1. [출처] 문자열 다루기|작성자 다코닝
   
   
   자료출처: http://blog.naver.com/bepark00?Redirect=Log&logNo=20011156070

이 글은 스프링노트에서 작성되었습니다.

string형은 ascii 코드 로 변환

1.  

   byte[] ascii = Encoding.ASCII.GetBytes("ABC");

   foreach (byte b in ascii)
   {
        Console.WriteLine("0x{0:x}", b);   // ascii 코드값 출력
   }
   
   

ascii 코드값을 다시 string 형으로 변환

1.  

   Console.WriteLine(Encoding.ASCII.GetString(ascii));

   
   

이 글은 스프링노트에서 작성되었습니다.

 is 연산자 : 두 객체가 동일한지 비교하는데 사용, is 연산자는 해당 객체가 is 오른쪽 형식과 호환되는지 확인만 한다. 객체 형식을 변경할 수 는 없다.

1. char data = 'a';
2. if(data is char)
3. System.Console.WriteLine("문자 데이터 입니다.");
4. else
5. System.Console.WriteLine("문자 데이터가 아닙니다.");

as 연산자 : 객체가 호환되지 않으면 null 값을 할당, 호환되면 형식(casting)을 시켜준다. as 연산자는 강제 형변환과 비슷하며 변환시 예외가 발생하면 null을 채운다.

1. string obj = data as string;
   if(obj != null)
   {
    ....
   }

아래의 형태는 as 연산자가 하는 기능이다.

이 글은 스프링노트에서 작성되었습니다.

문자열로 된 핵사 값(0,1,2,3,4,5,6,7,9,A,B,C,D,E,F)을 실제 핵사 값으로 변환한다.

string strHex = "ff";
int hex = int.Parse(strHex, System.Globalization.NumberStyles.HexNumber);
Console.WriteLine(hex); // 255 출력

핵사 값을 문자열로 변환

byte hex = 0xff;
string str = String.Format("{0:x2}", hex);
Console.WriteLine(str); // 문자열 ff 출력

이 글은 스프링노트에서 작성되었습니다.

Visual C# 2005 Keyboard Shortcut Reference Poster

 http://www.microsoft.com/downloads/details.aspx?familyid=C15D210D-A926-46A8-A586-31F8A2E576FE&displaylang=en

Visual C++ 2005 Keyboard Shortcut Reference Poster

http://www.microsoft.com/downloads/details.aspx?familyid=BCCF84F4-4136-48B2-B4EC-83EAA484DA20&displaylang=en

ctrl + F6 : 탭페이지 다음 이동
ctrl + shift + F6 : 탭페이지 이전 이동

F7 : 소스 코드 보기
shift + F7 : 폼 디자이너 보기

ctrl + z : 뒤로 돌리기
ctrl + y : 앞으로 돌리기
 
Ctrl + H : 바꾸기
Shift + Ctrl + F : 전체 솔루션에서 찾기
Shift + Ctrl + S : 모두 저장하기

Ctrl + F5 : 디버깅하지 않고 시작
F5 : 디버깅 시작
F6 : 솔루션 빌드
 

F9 : 중단점 설정
F10 : 프로시저 단위 실행
F11 : 한단계씩 코드 실행
F12 : 정의로 이동

ctrl + shift + F10 : 소스 코드 보기에서 context 메뉴 열기

이 글은 스프링노트에서 작성되었습니다.

About ThreadPool~

이번에는 ThreadPool에 대해서 소개할까 합니다. 혹시 이 부분에 대해서 잘 알고 계신가요? 아마 잘 알고 있다 보다는 “음~ 들어는 봤고, 대충 무엇인지는 알아!”라고 답 하시는 분들이 많을 것이라고 대략 추측해봅니다. 그런데, 이번에는 “대충 무엇인지는 알아!” 보다는 좀 더 자세하고, 세밀한 부분을 설명하고자 합니다.

솔직히 말씀 드리면, 본인이 이 ThreadPool에 흥미를 가져 소개하려고 할 때에, 참고하던 자료 중에 제가 좋아라 하는 Jeffery Richter가 쓴 MSND Magazine  Article이 있더라구요. Jeffery Richter의 글은 MSDN 등에 잘 언급되지 않은 내용들을 깊숙이~ 잘 소개하기로 나름 유명하신 분이며, 또한 .Net 분야에 상당히 내공이 깊어 많은 분들로부터 인정 받고 있기 때문에, 참고하지 않을 수 없었습니다. 그래서 이번 소개 글은 이 Article의 번역 본이라기 보다는, 번역본을 조금 더 이해하기 쉽게 또는 읽기 쉽게 소개하고자 하는 글이니 이점 참고하시기 바랍니다.

그럼 이제 대략 이 글에 대한 앞선 설명을 드렸으니, 이제부터 한번 시작해 보겠습니다.

여러분은 이번 주제인 ThreadPool이 왜 생겨났는지에 대한 내용을 혹시 들으신 적이 있으신가요? 혹은 ThreadPool이 어떤 기능을 수행하는지 잘 알고 계시나요? 이 질문에 대해서 정확히 아시는 분은 이 후의 글은 pass하셔도 상관 없겠습니다.

Jeffery Richter에 의하면 Microsoft는 수년 전부터(지금으로부터 따지면 상당히 오래 전에…) Thread가 개발자로 하여금 얼마나 잘 사용되어 지고 있는지 연구했다고 합니다. 그래서 이 결과를 분석하기 위해 조사를 시작했는데, 그 결과는 많은 개발자 들이 어플리케이션에서 발생하는 단일 작업을 처리하기 위해 새로운 쓰레드를 생성하고 작업이 완료되는 시점에서 생성된 쓰레드를 종료 시키는 일들이 빈번하게 발생하는 거였습니다.

그래서 Microsoft는 생각했답니다. 이미 생성된 쓰레드는 종료시키지 않고 다만 상태를 중지 시킨 후에 다음 요청이 들어오면 중지된 상태의 쓰레드를 다시 활성화 시켜 재사용 하도록 말이죠.

그렇지 않을 경우에, 어플리케이션에서 발생하는 작업을 처리하기 위해 쓰레드를 생성할 때 OS 레벨에서는 kernel 객체의 초기화, 그리고 쓰레드에서 사용되는 stack 메모리의 할당 및 초기화, Windows 운영 체제가 새로운 쓰레드가 생성 될 때 로드 된 assembly에게 DLL_THREAD_ATTACH라는 메시지를 보내기 위해 메모리에 로드 된 페이지의 손실 발생..  등등의 비 효율적인 일들이 벌어집니다.

그리고 나서 쓰레드가 동작을 완료하게 되면, 그때서야 여기에 할당 된 stack 메모리와 kernel 개체의 자원이 모두 해제됩니다.

이런 동작들을 통한 쓰래드의 생성과 소멸은 당연히 많은 오버헤드를 가져오게 됩니다.

이런 연구의 결과로 Microsoft는 Thread Pool을 만들게 되었고, 처음으로 Windows 2000에 적용이 되었습니다. 또한 .Net Framework 팀이 CLR을 설계할 당시에도 그들은 이 Thread Pool을 CLR 안에 탑재하기로 했답니다. 그 결과로 .Net Framework를 통한 managed 어플리케이션은 Thread Pool의 장점을 그대로 사용할 수 있게 되었을 뿐만 아니라 어플리케이션이 동작하는 운영 체제가 굳이 Windows 2000이 아닌 Windows 98과 같은 하위 버전일지라도 managed 어플리케이션은 Thread Pool을 사용해서 쓰레드를 관리하게 됩니다.

CLR이 초기화 될 때, ThreadPool은 아무런 Thread도 생성해서 가지고 있지 않습니다. 어플리케이션이 실행될 때 필요한 쓰레드를 ThreadPool에 요청하면 ThreadPool은 그때서야 새로운 쓰레드를 하나 생성하고 어플리케이션에 할당합니다. 그 이후부터 쓰레드가 작업을 완료하게 되면 바로 종료하지 않고 ThreadPool에 다시 반환되어 중지 상태로 ThreadPool에 머물게 됩니다.

그리고 또 다시 어플리케이션으로부터 쓰레드 요청이 들어오면, 이번에는 새로운 쓰레드를 생성하는 것이 아니라 ThreadPool에 의해 중지 상태에 있는 쓰레드를 활성화 시켜 재사용하도록 합니다. 이런 프로세스는 많은 오버헤드를 감소시킬 수 있습니다.

그런데 이번엔 조금 다른 경우를 한번 생각해 보죠. 어플리케이션이 ThreadPool에 의해 재사용되는 쓰레드를 사용하기 위해서, 오랫동안 단위 작업(task)들을 계속해서 큐(queue)에 쌓게 된다면 이것은 매 작업마다 쓰레드를 할당해서 처리하는 경우 보다 성능 면에서는 느릴 수 밖에 없을 것입니다.

하지만 이 경우는 어플리케이션이 실행되는 동안 ThreadPool에 생성되어 있는 쓰레드를 계속해서 재사용하기 때문에, 발생할 수 있는 엄청난 오버헤드를 감소시킨다는 잇점이 있습니다.

그런데 어플리케이션이 큐에 쌓여 있는 작업들을 각각의 쓰레드를 이용해서 처리하는 것 보다 빠르게 실행시키게 하려면, ThreadPool에 더 많은 쓰레드를 추가로 생성하면 될 것 같지만, 이렇게 새로운 쓰레드를 추가로 생성한다면 오버헤드가 증가되는 결과는 뻔 할 것입니다. 그렇겠죠?

그러나 어플리케이션은 자신이 실행되는 동안 처리해야 하는 모든 작업을 완료하기 위해, 우리 의생각과는 다르게 단지 몇 개의 쓰레드만을 요청하기 때문에 별로 문제 될 것이 없다고 합니다. 이런 점으로 미루어 봤을 때, ThreadPool을 사용하게 됨으로써 어플리케이션의 성능은 전반적으로 향상된다는 결론을 내릴 수 있습니다.

그런데, 위에서 한 말처럼 ThreadPool에 여러 개의 쓰레드를 생성해서 사용했다고 치죠.

만약 어플리케이션이 처리해야 할 작업의 수가 줄어 든다면, ThreadPool에 있는 여러 개의 쓰레드 들은 어떻게 될까요? 쓸 일도 없는데, 쓰레드를 종료시키지 않고 보관하고 있다면 이건 분명 리소스 낭비 밖에 안 될 것입니다. 실제 그렇다면, 음~ 문제입니다.

하지만 이러한 문제도 이미 Microsoft는 고려했다고 합니다. 이러한 경우, ThreadPool은 휴면 상태에 있는 쓰레드를 약 40초 동안 유지하고 있습니다. 그리고 40초가 경과했는데도 어플리케이션이 쓰레드를 요청하지 않아, 계속해서 정지 상태에 있어야 한다면, ThreadPool은 이러한 조건을 만족하는 쓰레드를 종료시켜 버린다고 합니다.

이렇게 됨으로써, stack 메모리와 kernel 생성에 소비되었던 리소스는 해제되어 사용 가능한 리소스가 더 늘어나게 됩니다.

그런데 ThreadPool을 설명하는 원문 글에서 Jeffery Richter는 쓰레드가 유휴 상태로 유지되는 40초라는 시간은 어느 문서에도 명시되어 있지 않는 시간이라고 이야기 합니다. 나중에 확인되면 수정한다고 하네요.(대략 개념을 정리하는데 도움을 주기 위해 사용된 수치 같습니다.)

이 글의 원문은 MSDN Magazine 2003년도 6월에 실린 “The CLR’S Thread Pool”이란 제목의 글이며, 주소는 아래에 적습니다. 이 글에는 이런 내용을 기반으로 몇 가지 더 설명하는 글이 있으며, 예제도 같이 포함되어 있는데, 이 내용은 다음에 전해 드리기로 하겠습니다. 이번에는 살짝 개념만 이해하고 계시면 될 것 같네요. 그럼 저는 여기서 이만 마치겠습니다.

감사합니다. ^o^v

*원문 글

http://msdn.microsoft.com/msdnmag/issues/03/06/NET/

Posted by zmeun

http://zmeun.tistory.com

이 글은 스프링노트에서 작성되었습니다.

 http://msdn.microsoft.com/ko-kr/library/system.threading.thread.isbackground(VS.80).aspx

이 글은 스프링노트에서 작성되었습니다.

 volatile : http://cafe.naver.com/carroty/47518

원문 : http://support.microsoft.com/default.aspx?scid=kb;en-us;815804

이 글은 스프링노트에서 작성되었습니다.

 스래드는 운영체제에서 프로세서 시간을 할당하는 기본 단위이며, 기본 단위로 2개 이상의 스래드가 해당 프로세스 내에서 코드를 실행할 수 있다. 스래드 컨텍스트(Thread context)는 스래드에서 사용하는 CPU레지스터, 스택 정보를 비롯하여 스래드에서 사용되는 모든 정보들을 포함하며, 이는 해당 호스트 프로세스의 주소 공간에 포함된다.

생성된 스레드는 아래의 그림과 같이 관리되는 프로세스 내의 하나 이상의 응용 프로그램 도메인에서 실행 될 수 있다. 각 응용 프로그램 도메인은 단일 스레드로 시작되지만, 사용자가 직접 응용 프로그램 도메인과 스래드를 생성할 수 있다. 동일한 응용 프로그램 도메인 안에서 생성된 스레드들은 생성된 응용 프로그램 도메인 내부에서는 자유롭게 이동(데이터 공유)이 가능하다.

현재 실행 중인 스레드가 할당받은 시간이 경과 되면 중단되고, 다른 스레드가 할당 받은 시간만큼 실행한다. 시스템이 한 스레드에서 다른 스레드로 전환(스위칭)될 때 섬점 스레드의 스레드 컨텍스트를 저장하고 스레드 큐에 저장된 다음 스레드의 스레드 컨텍스트를 다시 실행한다. 이런 과정이 사람이 느끼지 못할 정도의 시간안에 실행되다 보니 동시에 실행되는 느낌을 받게 되는 것이다.

다중 스레드의 장점

 두 개 이상의 스레드를 사용하는 것을 다중 스레드라고 한다. 다중 스레드를 사용하면 하나의 프로세서에서 여러개의 프로세서를 사용하는 효과를 볼 수 있다. 생성된 스레드들이 빠른 속도로 스위칭 되면서 마치 여러개의 프로세서들이 동시에 데이터를 처리하는 것 처럼 보이게 되는 것이다. 이는 사용자에 대한 응답성을 향상시키고, 작업을 동시에 완료시킬 수 있다.

다중 스레드의 단점

 스레드들은 프로세스 내의 데이터를 서로 공유하기 때문에, 생성된 스레드들이 공유자원을 사용하다 서로 충돌될 수 가 있다. 이런 공유 자원을 제대로 동기화 하지 못한다면, 교착 상태 또는 경쟁 상태와 같은 문제가 발생할 수 있다. 또한 많은 수의 스레드로 코드를 실행시키면 시스템의 성능이 저하되고, 그 구성이 복잡하여 버그가 많이 발생할 수 가있다. 때문에 스레드는 가능한 최대한 적게 사용하여 운영체제 리소스 사용을 최소화하고 성능을 향상시키는데 주력해야한다. AppDomain(응용 프로그램 도메인) 개채 및 스레드에서 필요한 컨텍스트 정보는 시스템 메모리에 저장된다. 때문에 AppDomain 개체 및 스레드의 수는 사용 가능한 메모리에 의해 제한된다.

- 동기화가 필요한 리소스

 시스템 리소스(예: 통신 포트)

 여러 프로세스에서 공유하는 리소스(예: 파일 처리)

 다중 스레드에서 액세스하는 단일 응용 프로그램 도메인의 리소스(예: 전역, 정적, 인스턴스 필드)

http://msdn.microsoft.com/ko-kr/library/6kac2kdh(VS.80).aspx

이 글은 스프링노트에서 작성되었습니다.

  운영체제에서는 프로세스를 이용하여 응용 프로그램을 구분 및 관리한다. .Net Framework는 프로세스를 아래와 같은 구조로 관리한다.

프로세스는 응용 프로그램 도메인을 기본적으로 하나를 가지고 있고, 그 안에 Main스레드를 가지고 있다.

 
하나의 프로세스안에 여러개의 응용 프로그램 도메인을 생성할 수 가 있다.

 운영체제 환경에서는 프로세스를 사용하여 응용 프로그램 간을 경계를 구분한다(MSDN에서는 격리라는 표현을 사용). 이는 한 응용 프로그램에서 실행 중인 코드가 서로 관련 없는 다른 응용 프로그램에 나쁜 영향을 주지 않게 한다. 이처럼 닷넷프레임워크 환경에서는 하나의 프로세스에 이런 효과를 줄 수 있다. 서로 다른 프로세스인 경우 프로세스 간에 크로스 프로세스 호출 또는 프로세스 스위칭으로 인한 추가 오버헤드가 발생하는데, 응용 프로그램 도메인을 사용하면, 응용 프로그램 도메인간에 경계를 구분하면서도, 위의 문제가 발생하지 않는 장점이 있다. 이는 단일 프로세스에서 여러 응용 프로그램을 실행할 수 있는 기능을 통해 서버 확장성이 증대되는 효과를 얻을 수 있다.

한 프로세스에서 여러개의 응용 프로그램 도메인이 생성되어 있고, 하나의 응용 프로그램 도메인에서 오류가 발생했다고 가정하자. 서로의 응용 프로그램 도메인은 각각 구분 되어 있기 때문에 다른 응용 프로그램 도메인에는 전혀 영향이 가지 않는다. 즉 오류가 발생한 응용 프로그램 도메인만 언로드 시킬 수 있다. 그리고 전체 프로세스를 중지 하지 않고도 개별적으로 응용 프로그램 도메인을 중지 할 수 도 있다.

 응용 프로그램 도메인 개요 : http://msdn.microsoft.com/ko-kr/library/2bh4z9hs(VS.80).aspx

이 글은 스프링노트에서 작성되었습니다.

1. Managed code 개요

 관리되는 코드(Managed code)는 CPU에서 직접 실행되는 네이티브 코드(Unmanged code)와 달리 가상 머신의 관리 하에서 실행되는 프로그램 코드이다. 관리되는 코드는 프로그래머에게 편리성, 보안성, 안정성을 보장한다. 주로 "관리되는 코드"라는 용어는 보편적으로 Microsoft 진영에서 많이 사용된다. C#, Visual Basci .NET등의 언어를 이용해서 관리되는 코드를 생성한다.

2. 닷넷 프레임워크 에서의 Managed code

 닷넷 프레임워크 즉 CLR에서 실행되는 모든 프로그램들은 관리되는 프로그램(Managed program)들이다(Win32 API로 만들어지는 프로그램들을 네이티브 코드 또는 비관리 프로그램이라 한다).

 모든 닷넷 기반 프로그램(관리되는 프로그램)들은 확인 프로세스를 통과해야만 실행 할 수 있다. 예외적으로 관리자가 이 프로세스를 건너 뛸 수 있는 권한을 부여한 경우에는 그냥 실행 될 수 있다. 확인 프로세스는 해당 코드들이 잘못 된 메모리 주소에 엑세스할 가능성이 있는지, 또는 실행 중인 프로세스를 정상 동작을 할 수 없게 하는 다른 작업을 수행하는지 등을 확인한다. 이 때문에 관리되는 코드 또는 프로그램이라고 부른다. 원천적으로 잘못된 메모리 주소에 엑세스하는 경우를 막고있기 때문에 CLR에서 실행되는 관리 코드들은 다른 프로세스가 사용하는 메모리 영역(또는 시스템이 사용하는 메모리 영역)등을 건드려서 시스템 전체가 다운되는 경우가 없다.

이 글은 스프링노트에서 작성되었습니다.

 http://msdn.microsoft.com/ko-kr/library/system.iformatprovider.aspx#Mtps_DropDownFilterText

이 글은 스프링노트에서 작성되었습니다.

  // type parameter T in angle brackets
    public class GenericList<T>
    {
        // The nested class is also generic on T
        private class Node
        {
            // T used in non-generic constructor
            public Node(T t)
            {
                next = null;
                data = t;
            }

            // T as private member data type
            private T data;

            // T as return type of property
            public T Data
            {
                get { return data; }
                set { data = value; }
            }

            private Node next;
            public Node Next
            {
                get { return next; }
                set { next = value; }
            }
        }

        private Node head;

        // constructor
        public GenericList()
        {
            head = null;
        }

        // T as method parameter type:
        public void AddHead(T t)
        {
            Node n = new Node(t);
            n.Next = head;
            head = n;
        }

        /// <summary>
        /// foreach 문을 사용하기 위해 GetEnumerator 정의
        /// </summary>
        /// <returns></returns>
        public IEnumerator<T> GetEnumerator()
        {
            Node current = head;

            while (current != null)
            {
                yield return current.Data;
                current = current.Next;
            }
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            // int is the type argument
            GenericList<int> list = new GenericList<int>();

            for (int x = 0; x < 10; x++)
            {
                list.AddHead(x);
            }

            foreach (int i in list)
            {
                System.Console.Write(i + " ");
            }
            System.Console.WriteLine("\nDone");

        }
    }

http://msdn.microsoft.com/en-us/library/0x6a29h6(VS.80).aspx

Local MSDN URL : ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.ko/dv_csref/html/7825ccb7-300d-4a82-88c4-629eadcd2741.htm

이 글은 스프링노트에서 작성되었습니다.

error MSB3323: Unable to find manifest signing certificate in the certificate store.

코드상의 오류는 없는데, 위의 오류가 뜨면서 컴파일이 안되는 경우가 있다.

정확이 왜 이런 현상이 일어나는지는 잘 모르겠다.

MSDN 포럼에서는 프로젝트 명을 변경했을 때도 이런 현상이 나온다는데,

나같은 경우엔 컴퓨터를 새로 세팅하고 나니 이런 현상이 나타났다.

아무튼 해결했으니 다행이다.

오류내용

------ Build started: Project: ChargeDisChargeControl, Configuration: Debug Any CPU ------
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1728,7): error MSB3323: Unable to find manifest signing certificate in the certificate store.
Done building project "ChargeDisChargeControl.csproj" -- FAILED.
========== Build: 2 succeeded or up-to-date, 1 failed, 0 skipped ==========

해결법

프로젝트 속성 -> "서명" 탭 -> "Sign the ClickOnce manifests" 체크 해제

원문

http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/f2b8771a-902c-4a9d-a2e1-cc8044e54421/

이 글은 스프링노트에서 작성되었습니다.