PJOTRIK: Nejsem si jist, jestli chápu. Myslíš tím syntaxi skriptovacích jazyků typu
success, result_list = do_something(blabla)
?
To v C# možná třeba v C# 7 bude, ale ta syntaxe zjednodušuje _použití_ té funkce, ale nic nemění na tom, že ta metoda nějaký konkrétní typ mít musí (na rozdíl od netypovaných skriptovacích jazyků) a tím bude právě takovýhle nějaký Tuple nebo něco podobného.

Jinak podobny navratovy typy jako

Tuple<List<T>, List<T>, List<Tuple<T, T>>>

jsou jedna vec co me na c# docela stve, chybi mi ta moznost prirazovat seznam do seznamu jako typicky v skriptovacich jazycich. Nemate nekdo prehled jestli se chysta nejaka sikovna ficura v tomhle smeru?

JULIEEHARSHAW: jako jo, to o premature optimization vsichni zname, ale tady srovnavame reseni ktery je primocary a v pripade takovyhleho zabaleni do metody i lip citelny s resenim ktery je neefektivni a v budoucim ctenari vyvola akorat zmateni proc se tam vsechny ty operace delaji a jestli tam neni nejaky nenapadny sideefect. Za me je vitez jasny - mluvim teda o pripade kdy ten kod pisu, u existujiciho otestovanyho kodu bych to bez duvodu nemenil.

Jeden algoritmicky dotaz, mam dva Listy A a B s objekty typu P.
Jak v C# co nejefektivneji ziskat seznam prvku, ktere jsou jenom v A, jen v B a potom seznam Tuplu prvku, ktere jsou v obou listech, vzdy Tuple<P,P> kde prvni prvek je z A a druhy z B?
Ted mam toto a premyslim, zda to udelat efektivneji, aby se zbytecne nealokovala pole a nebylo tam vice pruchodu navic.
Predpoklad je, ze pole jsou jiz sesortovane.

private static IEnumerable<T> CompareItems<T>(T[] oldItems, T[] newItems)
{
T[] removedItems = oldItems.Except(newItems).ToArray();
T[] addedItems = newItems.Except(oldItems).ToArray();

T[] sameOld = oldItems.Except(removedItems).ToArray();
T[] sameNew = newItems.Except(addedItems).ToArray();
Tuple<T, T>[] zip = sameOld.Zip(sameNew, (i1, i2) => new Tuple<T, T>(i1, i2)).ToArray();
}

JULIEEHARSHAW: Jj, mám, díky. Vyzkouším.

MORMEGIL: Jo takhle. Tak díky, už je mi to jasný.

P19: Hlavička sestává z klíče a hodnoty, přičemž klíč je od hodnoty oddělen dvojtečkou. V tomto případě tedy: Klíčem (označením hlavičky) je „Content-Type“, hodnotou této hlavičky je „text/plain; charset=UTF-16“. Nic víc, nic míň. Ale taktéž bych se přimlouval raději za UTF-8 místo UTF-16…

JULIEEHARSHAW: No dobře, a to tam přidám jak? message.Header.Add přijímá klíč value. Tak co je klíč? Content-Type a druhý klíč je charset?
Nebo tomu teda nerozumím.

PECA: to posledni cislo je tusim build, ne ? Takze paklize pro dva ruzne buildy zmenis API, pak asi neco spatne. Zkus pri zmene api amenit alespon tu treti pozici, ne-li druhou nebo prvni.

JULIEEHARSHAW: To je mi jasný, akorát jsem až doteď nevěděl, že poslední 2 čísla se neberou jako jiná verze. Takže tím pádem mi to přijde ještě záhadnější. Holt to musím ještě vyzkoušet.

JULIEEHARSHAW: Tak to potom nechápu, proč selhalo načítání assembly funkce.dll (uvedený soubor nebyl nalezen). Podle fuslogu se (díky volání z win32 aplikace) natáhl modul1, který si natáhl funkce (verze 1.0.0.1). Později se zavolal modul2, který se pokoušel natáhnout funkce.dll (verze 1.0.0.2), ale toto načtení selhalo. Podle fuslogu se funkce.dll hledaly vedle exe, pak ve složce s modul1 a tam to zheblo. Měl jsem dojem, že právě kvůli blbý verzi.

Tak to holt ještě jednou vyzkouším a pokud to nepůjde, budou se oba moduly deployovat spolu. Ono to bude celkem jedno. akorát že vícero win32 apps volá modul1, ale jenom jedna volá i modul2, tak jsem to nechtěl cpát úplně všude. Ale v zásadě jde o prd, až na moduly samotné je deployment prakticky totožný...

JULIEEHARSHAW: Potřebuju ty knihovny distribuovat s různými moduly. Ty moduly jsou COM servery a volají se z Win32 aplikace (Delphi 7). Aktuálně tam jsou 2 - říkejme jim modul1 a modul2. No a oba používají společné funkce.dll. Jenže když se vyrobí novější verze modulu2, která potřebujě novější verzi funkce, tak mám problém. Zkoušel jsem to dávat do různých složek a registrovat knihovny do GAC, ale někde bloudím. Mám modul1 i modul2 v samostatných složkách, jenže modul 1 se načte první a natáhne svoji verzi funkce.dll. Když pak nabíhá modul2, zakopne o starší verzi funkce.dll nakešovanou při načítání modulu1.

všechny to má strongname, ale když jsem zkoušel registraci dvou různých verzí funkce.dll v oddělených složkách do GAC, tak mi to nějak nešlo. Třeba jsem to dělal špatně. Ale přišlo mi lepší, rozlišit ta dll už v názvu - i kvůli manipulaci, distribuci a tak. Pro testy si to samozřejmě můžu přejmenovat ručně, ale nakonec bych to stejně potřeboval dělat automaticky při buildu.

Výsledek by potom byl, že bych měl všechna dll v jedný složce s win32 exe a mohly by tam být různé verze vedle sebe... (doufám)

Potřeboval bych do názvu assembly dostat verzi, a dost možná i namespace (radši). Něco jako "firma.funkce.14.2.0.1.dll".
Získal jsem dojem, že samotné VS 2013 to neumí. A googlu se ptám asi blbě. Existuje nějaké jednoduché řešení?
Děkuji za případné rady.

VERLIBA: Přidal jsem:

message.HeadersEncoding = Encoding.Unicode;
message.Headers.Add("Content-Type ", " text/plain");
message.Headers.Add("charset ", " UTF-16");

A vůbec to nepomohlo.. :/

VERLIBA: Plain text. Ale naivně jsem si myslel, že když kódování nastavím na Unicode, že to pošle i správnou hlavičku. Zkusím to.

P19: posilas html, text, nebo multipart ? v multipartu se da nastavit kodovani ke kazde casti zvlast. Vlastne asi i k obyc textu se da pridat hlavicka Content-Type: text/plain; charset=UTF-8