2013-08-12 2 views
6

형식 공급자를 [<TypeProviderAssembly()>][<EntryPoint>] 인 * .exe 파일로 만들 수없는 이유는 무엇입니까? 내가 #r @"d:\TP\bin\Debug\MyTypeProvider.exe"를 사용하여 TP 등 참조하려고하면F # * .exe 파일로 컴파일 된 공급자 유형

, 나는 다음을 참조 : 그것이 있어야하기 때문에

test.fsx(3,1): error FS3031: The type provider 'd:\TP\bin\Debug\MyTypeProvider.exe' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'MyTypeProvider' which cannot be loaded or doesn't exist. Could not load file or assembly 'file:///d:\TP\bin\Debug\MyTypeProvider.dll' or one of its dependencies. The system cannot find the file specified.

내가, 별도의 프로세스에서 형식 유추 런타임이 필요 64bit (32bit VS 과정과는 달리). 하지만 모든 것을 하나의 파일로 압축하여 VS에서 참조하고 외부 프로세스로 시작하려고합니다.

답변

2

아마도 EXE 대신 항상 DLL을 찾는 좋은 근본적인 이유가있을 수 있습니다. 그러나 이것은 임의의 제한 사항 일 수 있습니다.

TypeProviderAssemblyAttribute 생성자 (예 : [<TypeProviderAssembly("MyExe, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null")>])에 어셈블리의 전체 이름을 제공하면 FSI에서 작동하도록 할 수 있지만 IntelliSense가 작동하지 않고 다른 프로젝트의 TP를 사용할 수 없습니다. 팀에 버그를 제기하는 것을 고려해보십시오. 그러나 시나리오 대신 DLL 대신 EXE가 필요한 이유를 정당화 할 수 있다면 도움이 될 것입니다.

+0

TP가 SharePoint에 연결할 수 있어야합니다. '64bit' 프로세스에서만 가능합니다. VS는 IntelliSense를 의미하는 32 비트 앱입니다. 유형 제공 업체에서 직접 할 수 없습니다. 내가 볼 수있는 유일한 해결책은 '64 비트'프로세스를 별도로 시작하고 WCF 명명 된 파이프를 사용하여 이들 사이에서 통신하는 것입니다. 하나의 exe에 서비스와 클라이언트를 묶는 것이 좋습니다. –

+0

[현재 구현] (https://github.com/sergey-tihon/PowerShellTypeProvider)을 볼 수 있습니다. 그러나 나는이 프로젝트들을 하나로 합치기를 원한다. 이 경우에는 사용하기가 더 쉬울 것이라고 생각합니다. –