Potřeboval bych pomoc s roztlačením webservice. Napsal jsem si (celkem primitivní) web service. Možná to bude problém konfigurace ISS, nebo spíš nastavení web.config aplikace (služby), ale fakt netuším.
Služba klasicky vraci WSDL, jenže uvnitř je interní adresa serveru, nikoli adresa viditelná z internetu. Konkrétně: http://server.aginfo.cz/epstest/Service.svc?wsdl
Ve vnitřní síti server vidím jako http://ag2008.firma.aginfo.cz a na této adrese mi to i funguje, ale jakmile to zavolám zvenku, tak v browseru se sice wsdl zobrazí, ale při pokusu o přidání služby do WCF Test Clienta to napíše: "Failed to add a service. Service metadata may not be accessible. Make sure your service is running and exposing metadata." Ve web.config mám toto:
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="True"/>
</behavior>
</serviceBehaviors>
</behaviors>

Zkoušel jsem upravit konfiguraci, podle toho, co se mi podařilo vyčíst z helpu a pomocí googlu z netu, ale vyhodí mi to do browseru tohle: Chybová zpráva analýzy: Neexistuje chování koncového bodu nazvané ServiceBehaviors.
web.config obsahuje toto:
<services>
<service name="Service" behaviorConfiguration="ServiceBehaviors" >
<endpoint address="http://server.aginfo.cz/epstest/Service.svc" binding="basicHttpBinding" behaviorConfiguration="ServiceBehaviors" contract="IService" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehaviors">
<serviceMetadata httpGetEnabled="true" httpGetUrl="http://server.aginfo.cz/epstest/Service.svc"/>
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceAuthorization principalPermissionMode="UseAspNetRoles" roleProviderName="FbRoleProvider" />
</behavior>
</serviceBehaviors>
</behaviors>

Nějaké rady, doporučení? :-(

SLUPKA: jo, mas pravdu vlastne - plnohodnotnej Thread prezije (do recyklace poolu)..

VIRTUALVOID: pokud máš zaplé impersonation, tak pak záleží jestli máš nějaké omezení (třeba jen na nějaké uživatele). jinak, když dojde k impersonaci, tak pouze na tom vlákně, které obsluhuje request (když uděláš něco třeba na threadpoolu, tak tam bude vlákno běžet opět pod defaultním uživatelem (tím, co je nastaveno v app poolu).

NECROMAN: sharepoint to nieje, ale app ma nastaveny windows auth, a asp.net impersonation. a celkom ma myli kde je to pod akou identitou.

VIRTUALVOID: Pokud se jedna o SharePoint, tak tam muzes pouzit impersonaci a "vydavat" se u urcite operace za jineho usera, ale to asi neni tvuj pripad.

VIRTUALVOID: ten zvolený - "networkService"

NECROMAN: jasne, ale ten pool ma identitu toho uzivatela, ci toho networkService ?

VIRTUALVOID: kazdy app pool bezi pod zvolenym uctem a pod pravy tohoto uctu muze vykonavat operace, jako treba pristupovat k souborum a pod, pokud se nepletu.

BUTHRAKAUR: ale to je limit pro request... po tom čase ti to zabije vlákno, které obsluhuje request...

Hi, zvlastna otazka :

Mam webovu aplikaciu, ktora je typu "windows auth". Jej aplikacny pool ma ako identitu nastavene "networkService".

A teraz, ak ma aplikacia autentikuje s nejakym mojim domenovym uctom, pod akou identitou bezi ten process,resp. mozno aj pool aplikacie ?

dik

SLUPKA: IIS default je vazne 110s a je IMO prasarna ten limit zvedat - IIS request proste neni urcenej na dlouhotrvajici veci.

http://msdn.microsoft.com/en-us/library/vstudio/e1f13641(v=vs.100).aspx => executionTimeout

Planujete letet nekdo na dubnovou Build konferenci? Zitra od 18 zacina registrace za lidovych $2095
Microsoft Build Developer Conference | April 2 – 4, 2014
http://www.buildwindows.com

BUTHRAKAUR: tohle bych tipnul spíš na nějaké konkrétní nastavení IIS (docela by to sedělo na nějaké české hostingy, protože český asp.net hosting za moc nestojí)... já jsem se s tím v praxi nesetkal... samozřejmě, pokud se počítá s tím, že ten task poběží až takhle dlouho, tak bych to určitě nedělal takhle naivně (zákon schválnosti je neúprosný a recycle bys prostě potkal)...

Omlouvám se za SPAM, ale mohlo by někoho možná zaujmout:
Sháním .NET vývojáře pro projekt který se zabývá webhostingem, serverhostingem, housingem... Jedná se o dlouhodobou spolupráci při reimplementaci stávajících řešení našeho klienta do technologie .NET.

Dlouhodobá spolupráce – cca 1-2 roky.

Požadavky:
Nutná znalost:
.NET framework (2.0 - 4.0+)
C#
Webové služby Soap (asmx a WCF)
Linq-to-object
Asp.NET (WebForms a/nebo MVC)
T-Sql (Query)

Výhodou:
Multithreading
Unit testing
REST
T-Sql (Functions, Stored Procedures)
Application Lifecycle Management
JQuery

Pokud by měl někdo zájem, prosím do pošty.
Díky.

NECROMAN: strong name a podpis neměla ani jedna ;)

TOOMIX: maji ty dve puvodni knihovny Strong Name a i digitalni podpis? Caso takovy problem vznika, pokud nemaji Strong Name a nejlepe kdyz jeste maji stejne cislo assembly, to potom snadno vzniknou problemy pri nacitani.

Rád bych se zeptal na věc, na kterou jsem včera narazil a docela nemile mě překvapila.

Programuju v .NET 4.0 aplikaci, která načítá data po modbusu. Bohužel potřebuju 2 knihovny, přičemž obě mají stejný namespace, ale každá má trochu jiné metody (jednu používám pro komunikaci se zařízením 1, druhou pro komunikaci se zařízením 2). Problém nastal v tom, že se obě knihovny jmenovaly stejně - Modbus.dll. Druhou jsem tedy normálně přejmenoval na Modbus2.dll (aby mi VS neřvalo, že už tam jednu assembly s názvem Modbus mám), a obě nahodil jako referenci k projektu (Modbus, Modbus 2). Oběma referencím jsem nastavil alias, následně do tříd dal

extern alias "název aliasu dll, kterou měla třída použít";

Po zbuildování proběhlo všechno v pořádku, ale jakmile se měla udělat instance jedný z těhlech dvou tříd, spadlo to na FileNotFoundException.

Problém jsem vyřešil tak, že jsem na netu našel zdrojáky k 1. knihovně, přepsal namespacy (možná i zbytečně), assembly name a zbuildoval si novou knihovnu.

Je mi jasný, že přejmenováním dll nedojde ke změně assembly name, ale proč to nešlo přes ty aliasy? Díky

NECROMAN: ja som to riesil cez signalr, persistent connection. ma to tu vyhodu, ze si vies pripadne poslat aj progress. ale to by si musel frontend/app programovat viacmenej asi v js.

SLUPKA, NECROMAN: mozna se pletu, ale matne si vzpominam, ze IISko standardne po 120s zabiji requestem vyprodukovany thready, ne? Pokud je to vazne dele trvajici async task, tak bych to videl spis na klasickej pripad pro messaging.