Hirdetés
- "A homoszexualitás természetellenes" 😠
- Billentyűzettel autóznék újra, van még ilyen gém?
- Milyen mosógépet vegyek?
- Szólánc.
- CTEK akkumulátor töltő és másolatai
- Mindent a StreamSharkról!
- Nagy "hülyétkapokazapróktól" topik
- A laposföld elmebaj: Vissza a jövőbe!
- Hegyen-völgyön, Chongqing
- Fűzzük össze a szavakat :)
Új hozzászólás Aktív témák
-
dqdb
nagyúr
válasz Peter Kiss #8398 üzenetére
System32 vs SysWOW64 mappa
64 bites Windowson egy 64 bites alkalmazás a System32 mappát látja System32 mappaként, míg egy 32 bites alkalmazás a WoW64 alrendszer miatt a SysWOW64 mappát látja System32 mappaként. Szóval ott volt a meghívott alkalmazás, csak a rossz System32 mappában.
Registrynél van még hasonló virtualizálás a Wow6432Node node alatt.
sztanozs: az a pont a .dll-ekre és egy egyéb in-process megoldásokra vonatkozik, itt külön folyamat jön létre.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Azért, mert a GZDecompress által átugrott első két byte hiányzik a GZCompress által létrehozott adatból.
Streamek és más IDisposable objektumok esetében mindig használd a using kulcsszót.
public static string GZDecompress(string compressedString)
{
try
{
using (var memStream = new MemoryStream(Convert.FromBase64String(compressedString)))
{
memStream.ReadByte();
memStream.ReadByte();
using (var deflate = new DeflateStream(memStream, CompressionMode.Decompress))
using (var reader = new StreamReader(deflate, System.Text.Encoding.UTF8))
{
var decompressedString = reader.ReadToEnd();
return decompressedString;
}
}
}
catch (Exception)
{
return String.Empty;
}
}
public static string GZCompress(string decompressedString)
{
try
{
using (var memStream = new MemoryStream())
{
memStream.WriteByte(0x78);
memStream.WriteByte(0x9c);
var input = Encoding.UTF8.GetBytes(decompressedString);
using (var deflate = new DeflateStream(memStream, CompressionMode.Compress))
{
deflate.Write(input, 0, input.Length);
}
return Convert.ToBase64String(memStream.ToArray());
}
}
catch
{
return String.Empty;
}
}Azt nem egészen értem, hogy miért nem HTTP szinten van megvalósítva a tömörítés, miért kell a kliens logikáját ezzel terhelni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Már csak érdekességből kérdezem: mi az a két bájt, amit kitömörítéskor le kell szedni, betömörítéskor meg hozzá kell biggyeszteni?
2.2 fejezetben a CMF + FLG rész.Alapvetően a webszerver esetén is megvan, de egyrészt a JSON forrása eltérő is lehet, és ott nem biztos, hogy a HTTP-ben történik a tömörítés, másrészt a kliens által visszaküldött anyagot is tömöríteni kell.
A kliens ugyanúgy támogathatja a tömörített adatküldést. Jelenleg fogsz egy JSON struktúrát, összetömöríted, hogy kisebb legyen a forgalmazott adatmennyiség, majd azzal, hogy base64 kódoláson tolod át, generálsz feleslegesen +33% forgalmat.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz bazsy1981 #8499 üzenetére
Ezt a funkcionalitást az OpenFileDialog mögött álló Win32 API függvény végzi, te nem kapod meg az értesítést arról, hogy drag and drop történt az ablakból indítva, ahogyan arról sem kapsz értesítést, ha mappát hoznak létre, és arról sem, hogy átneveztek egy fájlt (pontosítva igen, de finoman szólva sem egyszerű ezt elérni). Ha ilyet szeretnél, akkor neked kell megvalósítanod a fájllista kezelését (például erre építve, de találni erre más megvalósítást is).
UX szempontjából határozottan furcsa lenne az általad kitalált megoldás, lényegében nem arra használnál egy API-t, mint amire szánták, hanem kicsavarnád és abszolút nem intuitívvé tennéd a használatot.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz bandi0000 #8538 üzenetére
(a + bi)(c + di) = ac + adi + bci + bdi² = ac + (ad + bc)i + bdi²
Mivel i = √-1, ezért i² = -1, azaz
ac + (ad + bc)i + bdi² = ac + (ad + bc)i + bd × (-1) = (ac - bd) + (ad + bc)i
Vagyis:
(a + bi)*(c + di) = (ac - bd) + (ad + bc)i
Ha megnézed ennek a .NET Core-ban található implementációját, akkor ott pontosan ez szerepel:
public static Complex Multiply(Complex left, Complex right)
{
return left * right;
}
public static Complex operator *(Complex left, Complex right)
{
// Multiplication: (a + bi)(c + di) = (ac -bd) + (bc + ad)i
double result_realpart = (left.m_real * right.m_real) - (left.m_imaginary * right.m_imaginary);
double result_imaginarypart = (left.m_imaginary * right.m_real) + (left.m_real * right.m_imaginary);
return new Complex(result_realpart, result_imaginarypart);
}Vagyis akárhogyan nézem, jól szoroz össze két komplex számot az ajánlott osztály (csúnya is lenne, ha nem).
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz Peter Kiss #8596 üzenetére
Pedig nincsen szebb annál, amikor az SAP interfészen a mező neve egy rövidített német, egy rövidített angol és egy rövidített magyar szóból áll össze, és ezeket részeket az aláhúzás és kötőjel véletlenszerű kombinációja választja el
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz t-shirt #8650 üzenetére
A soros port egy olyan állatfajta, amit egyszerre csak egy példányban lehet megnyitni, ráadásul full duplex átvitelre képes, így azon az egy példányon keresztül mehet a küldés-fogadás.
Emellett érdemes rászokni a
using
használatára olyan esetben, amikorIDisposable
interfészt megvalósító osztállyal dolgozol, mint aSerialPort
, hogy exception esetében is garantáltan meghívódjon aDispose
metódus.Vakon belemódosítva valami ilyesmi lenne:
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
using (var port = new SerialPort("COM4"))
{
port.BaudRate = 9600;
port.Parity = Parity.None;
port.StopBits = StopBits.One;
port.DataBits = 8;
port.Handshake = Handshake.None;
port.RtsEnable = true;
port.DataReceived += Port_DataReceived;
port.Open();
Console.WriteLine("Küldj üzenetet a COM4 portra:");
while (!(Console.KeyAvailable && Console.ReadKey(true).Key == ConsoleKey.Escape)) {
WriteData(port, Console.ReadLine());
}
}
private static void WriteData(SerialPort port, string readLine)
{
port.WriteLine(readLine);
}
private static void Port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
var sp = (SerialPort)sender;
string dataReceived = sp.ReadExisting();
Console.WriteLine("A vissza jövö uzenet a COM4 port ra: " + dataReceived);
}
}
}tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz t-shirt #8656 üzenetére
Ha a kommunikációban a PC a kliens és az eszköz a szerver, ami a kérésekre válaszol, akkor érdemes egy megfelelő timeout értéket választani és beállítani, amin belül a túloldalnak biztosan válaszolni kell, a DataReceived esemény kezelésére nincsen szükség, és a Read metódussal kiolvasni a választ, ez vár a timeoutnak megfelelő időt, ha nem kap választ. A válasz olvasásának módján a protokolltól függően lehet finomítani (fejléc van-e, kiderül-e előre, mekkora lesz az üzenet és hasonlók).
Ha a kommunikációban a PC a szerver és az eszköz a kliens, aminek a kéréseire válaszol a PC, akkor célszerű lenne a DataReceived eseményben egy AutoResetEvent példányt élesíteni Set metódussal, a fő ciklusban pedig WaitOne hívással várakozni rá, és ott kiolvasni a kapott adatot. Így nem pörögne 100%-on egy mag feleslegesen várakozás közben.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz t-shirt #8662 üzenetére
Ez esetben elég ennyi módosítás, és nem fogja a CPU-t tekerni feleslegesen:
using (var port = new SerialPort("COM" + cp))
{
port.BaudRate = 9600;
port.Parity = Parity.None;
port.StopBits = StopBits.One;
port.DataBits = 8;
port.Handshake = Handshake.None;
port.RtsEnable = true;
port.DataReceived += Port_DataReceived;
port.Open();
while (fo_tomb_index <= (fo_tomb_merete-1))
{
receivedNewRequest.WaitOne();
var s = port.ReadExisting();
WriteData(port, fo_tomb[fo_tomb_index]);
Console.WriteLine(fo_tomb[fo_tomb_index]);
fo_tomb_index++;
}
}
}
private static WaitHandle receivedNewRequest = new AutoResetEvent(false);
private static void WriteData(SerialPort port, string readLine)
{
port.WriteLine(readLine);
}
private static void Port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
receivedNewRequest.Set();
}joysefke: a kódodnál nem azért nem fogja feleslegesen terhelni a CPU-t, mert áttetted a futását egy másik szálra, hanem azért nem, mert a példádban a SerialPort.ReadLine hívást használod, ami ReadTimeout időt vár, mielőtt visszatérne, ha nincsen adat, és közben értelmes módon várakozik.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz RedHarlow #8720 üzenetére
Nem ártana, ha véletlenszerűen kiollózott részletek helyett a komplett osztály forrását betennéd, mert így senki sem fog tudni semmi értelmeset mondani, legfeljebb találgatni, hogy mit csinálhattál.
Az utolsó előtti hozzászólásodban például az látszik, hogy a pcpath egy lokális változó, aminek értéket adsz, aztán nem kezdesz vele semmit sem.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Az Office interop arról szól, hogy egy futó/akkor elindított Excel alkalmazást vezérelsz távolról a COM interfészén keresztül, hogy hajtson végre ilyen-olyan műveleteket, így mindenképpen telepített kliens kell neki mind fejlesztés közben, mind máshová feltelepítve.
Ha Excel telepítés nélkül szeretnél .xlsx fájlokat kezelni, akkor nézz rá az EPPlus és Open XML SDK projektekre.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz RedHarlow #8736 üzenetére
[link]
erre nem kell regexunrecognised escape characterre jutottam. Stackoverflow-on\googleben\youtubeon is kerestem hasonló hibákat de nem igazán jött össze.
Pedig a nálam legalábbis első találat lenne a megfejtés. Vagy @" vagy .*\\..tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Ha az Excelben adott mező formátuma dátum, akkor a
GetCellValue
függvényből egész számot kapsz vissza szövegként, ha idő, akkor egynél kisebb törtet, ha dátum és idő, akkor törtet. Ha van törtrész, akkor a szövegben tizedespont szerepel, amire aDouble.Parse(value)
akkor fog lefutni, ha olyan regionális beállításod van, ami tizedespontot használ, vagy második paraméterként átadsz egy ilyen locale-t. Az előző hozzászólásomban szereplőCultureInfio.InvariantCulture
ilyen, írd be, és működni fog.43566.556944444441 => 2019.04.11. 13:22:00
43567 => 2019.04.12. 0:00:00[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Az Excel fájlban a B1 mezőben van a dátum, nem a B2-ben, ahogyan a forrásban szerepel.
Két megjegyzés:
1. oké, hogy az elvi lehetőség adott a közel teljes UTF8 használatára a forráskódban a szimbólumok nevéhez, azonban nem túl szerencsés ékezetes függvény- és változóneveket használni (és úgy általában nem angolt sem)
2. a GetCellValue metódust át kellene dolgozni, mert jelenleg minden érték kiolvasásánál megnyitod az Excel fájlt, megkeresed a munkalapot, ott mezőt, kiolvasod, majd lezársz mindenttAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Az Iodine támogatja, ezt már sztanozs is jelezte. A másik csak egy egyszerű frontend, elé kell tenni egy rendes webszervert TLS proxynak.
A chrome is, meg a firefox is konkrétan blokkolják, ami nem támogat https-t, legyen az akár csak egy webapi kiszolgáló.
Rossz megközelítés: nem azért kell TLS-t használni, mert a Chrome és a Firefox sír a hiánya miatt, hanem azért, hogy védett legyen a kapcsolat, és ettől mellékesen a Chrome és Firefox boldog lesz. Nem tudom másoknál hogyan van, nálunk már sok-sok éve a fejlesztői rendszerekben is TLS-sel védett minden kapcsolat.könnyű megírni egyébként is
Ja, ha ilyen könnyű összedobni egy skálázható-clusterezhető megoldást, akkor nem szóltam. Kár, hogy a fél világ ezt nem tudja, és Redisre épít, ha cache kell neki.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
így utólag már mezei file-ok és memória blokkok elegendőek az sql szerver helyett, ami bizony egyszerűbbé teszi a dolgokat - akár hiszed, akár nem.
Tudom, hogy egyszerűbbé tudja tenni a fájlokat használó megoldás az életet, rendszeresen használok ilyet a storage interfész mockolására tesztekben. Persze éles környezetben nem, hiszen a redundancia, rendelkezésre állás kifejezések léteznek, és amíg egy clusterezhető middleware elintézi helyettem az adatok node-ok közötti replikálását, addig egy fájlalapú megoldásnál nekem kellene ezt nulláról lefejleszteni. Nem lehetetlen, csak rettenetesen időigényes, és akármennyi erőforrást is elégetek rá, akármennyi tesztet gyártok hozzá, a saját implementáció kevésbé lesz tesztelve éles szituációban, mint az elterjedt 3rd party megoldások. Vannak esetek, amikor érdemes feltalálni a spanyolviaszt, mert megéri, ez szerintem határozottan nem az.Részemről inkább azt a kérdést tartom nehezen megválaszolhatónak, hogy a c# topikban miért c stuffokat preferálnak a népek?
Én sosem a nyelvhez, hanem mindig feladathoz választok middleware-t, az pedig, hogy miben írták, teljesen irreleváns addig, amíg van hozzá .NET vagy REST API. Így aztán az egyik rendszerünk tipikus telepítése használ Javában, Erlangban és Góban készített middleware-eket (másikban akad Ruby is), miközben a rendszerünk forrása egyetlen sornyi Javát, Erlangot és Gót sem tartalmaz. Nem azért, mert a szivárványos össznyelvi összeborulás volt a cél, hanem azért, mert adott részfeladatra az adott komponenst találtuk a legjobbnak.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz joysefke #8865 üzenetére
<PackageReference Include="YoutubeExplode" Version="4.7.9" Condition=" '$(Configuration)' != 'GooglePlayRelease' and '$(Configuration)' != 'GooglePlayDebug' "/>
Így egyszerűbb, nem kell a
Choose
blokk, elég az eredetiPackageReference
elemet módosítani. Csomagfrissítésnél nézz majd rá a .csproj fájlra, megmaradt-e a feltétel benne.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz joysefke #8867 üzenetére
Nem érdemes próbálkozni, a linkelt issue alapján nem működik az én megoldásom, csak az általad talált workaround.
Mindig "élmény" olvasni a NuGet fejlesztőcsapat arrogáns hozzáállását a bejelentett problémákra és szívni, amikor valamilyen újításuktól eltörik a build folyamat
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Rosszul közelíted meg a dolgokat.
Konzolos alkalmazás háromféle módon indulhat el Windows alatt:
1. egy másik konzolos alkalmazásból
2. egy másik konzolos alkalmazásból kimenetet és esetleg bemenetet átirányítva
3. nem konzolos alkalmazásbólAz első esetben az alkalmazásod a hívó alkalmazás ablakát örökli meg az ott beállított mérettel, historyval és színekkel, ezt általában nem illik* felülbírálni kódból, mert te ott vendég vagy.
A második esetben az előző annyival bővül, hogy a sima
Console.WriteLine
hívások a képernyőre ki sem kerülnek, szóval itt a hívó ablakának beállításait kódból nemcsak nem illik felülbírálni, de értelmetlen is. Ezt az esetet aConsole.IsOutputRedirected
propertyvel tudod érzékelni.A harmadik esetben a Windows megnézi, hogy az adott elérési úttal rendelkező alkalmazáshoz van-e beállítva alapértelmezett ablakméret/betűtípus/szín/stb. Ha igen, akkor azokkal indítja el az alkalmazásodat, egyébként a cmd.exe-hez tartozó alapbeállításokkal. Ekkor a kapott méreteket és egyéb beállításokat felül lehet bírálni kódból, de általában felesleges és nem szerencsés*, mert ezzel elveszed a felhasználó elől a saját igényeinek megfelelő beállítás alkalmazását. A legjobb megoldás vagy egy megfelelően felparaméterezett shortcut készítése, vagy futó alkalmazás mellett az ablakához tartozó menüben (fejléc bal oldalán lévő ikonra kattintva Defaults) átállítani, és onnantól kezdve az ott megadott értékekkel fog indulni az alkalmazás (egy adott konfigurációhoz egyszer kell beállítani VS-ből indítva, és onnantól kezdve mindig úgy fog elindulni).
* ha az alkalmazásod sima szövegkiíratás helyett valami ncurses-szerű szöveges UI-jal rendelkezik, aminek például a historyban görgetés keresztbe tesz, akkor ott természetesen kódból mindig olyanra be kell állítani az ablakot, amilyenhez a UI tervezve van (de itt is érdemes úgy megoldani a dolgokat, ha lehetséges, hogy a felhasználó által beállított ablakmérethez igazodjon a felület, mint például a FAR Manager esetében)
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz RedHarlow #8917 üzenetére
Valami ilyesmi kellene neked fapados megvalósítással:
var delayBetweenRetries = 30 * 1000;
var maxRetries = 3;
var retryCount = 0;
var expectedFileCount = GetExpectedRemoteFileCount();
var actualFileCount = 0;
for (;;)
{
var fileCount = GetRemoteFileCount();
if (fileCount > expectedFileCount)
{
throw new TooManyRemoteFilesException();
}
else if (fileCount == expectedFileCount)
{
break;
}
else if (fileCount == actualFileCount)
{
if (++retryCount > maxRetries)
throw new TooManyRetriesException();
}
else if (fileCount > actualFileCount)
{
retryCount = 0;
actualFileCount = fileCount;
}
else
{
throw new RemoteFileCountMismatchException();
}
Thread.Sleep(delayBetweenRetries);
}Ha a távoli szerveren drága az exportálás és az SCP kapcsolat szeret megszakadni, akkor érdemes úgy megírni a
GetRemoteFileCount()
metódust, hogy az kezelje a kapcsolat újraépítését. És persze nem árt a fájlok számának figyelése mellett a tartalmukat is ellenőrizni később.Ha sokkal bonyolultabb hibatűrést megvalósító esetek is előfordulhatnak, akkor a Polly library az egyik legjobb arra a célra, hogy ne kelljen minden távoli hívásnál/lekérdezésnél 30-50 soros logikát megírni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
a command.CommandText nem a behelyettesített értéket adja vissza
Az a property a beállított parancsot adja vissza, amiben paraméterek szerepelnek konkrét értékek helyett. A paraméterek behelyettesítése a szerveren fog megtörténni a már parse-olt SQL parancs felhasználásával, így a komplett parancs olyan szöveges formában, ahogyan te szeretted volna, sosem létezik.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz zsolti_20 #8960 üzenetére
Ha a második program az elsőt indítja, akkor sima output átirányítással megoldható a ProcessStartInfo megfelelő paraméterezésével. Ha nem, és PID vagy .exe neve alapján kell megkeresni az ablakát, akkor szintén megoldható, de ehhez kell egy jó adag P/Invoke. Ha ugyanabban a parancssorban egymás után indítod el, akkor szintén megoldható.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz zsolti_20 #8964 üzenetére
A három felvázolt eset szempontjában teljesen irreleváns, ki írta, csak az számít, hogyan kerül futtatásra az első alkalmazás (feltéve ha konzolos alkalmazás egyáltalán, mert a WriteLine-os példádból az jött le, ha nem, akkor az egy merőben eltérő plusz eset).
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz zsolti_20 #9021 üzenetére
[link]
Forrást végignézve ez jó lesz neked, az előzőtől annyi az eltérés, hogy lekérdezi az aktív ablakot, és annak a koordinátáit használja fel.Azt azért hozzá kell tenni, hogy nem az aktív ablakról tudsz képernyőmentést készíteni, hanem a képernyő azon részéről, ahol az aktív ablak van. Ez a kettő általában megegyezik, azonban abban az esetben, ha az aktív ablakot részben takarja egy másik ablak, amire a z-order szerint feljebb van, akkor azon a részen a másik ablak fog látszani a mentésen.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Vagy code injection kellene hozzá, amire jellemzően minden vírusirtó ugrana, amiben van alapszintű BB vagy HIPS. Ráadásul úgy is csak bonyolultan (BeginPaint és EndPaint eltérítése, direkt WM_PAINT kiadása) és okozhatna alkalmazásszintű problémákat.
Vagy meg kell keresni a topmost ablakokat, amelyek kitakarnának a képből, és ezeket el kell rejteni arra az időre.
Szerintem egyik sem éri meg a befektetett időt.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
-
dqdb
nagyúr
Hogy tudom megvalósítani, hogy a hívott URL szerinti metódus fussék le és a kimenetét (return string) adja vissza a HttpListener outputjaként?
Arequest.Uri.Path
tartalmazza a relatív címet, a routingot ez alapján tudod megvalósítani.Ha eléggé nagy a beeső kérés vagy válasz, akkor stringek helyett szerencsésebb streamek használata. Ha van adatbázis vagy más távoli elérés a háttérben, akkor pedig az aszinkron kód írása. Ha az IIS/Kestrel elkerülése a cél beépített HTTP szerverrel, akkor nézd meg ezt a csomagot, könnyű használni, van benne SSL, alapszintű routing támogatás és teljesen aszinkron a teljes felülete.
Annyi, hogy a server.exe egy lokális Win szerveren futna, nyilván ezt task scheduler egyszer elindítaná és ott szépen futna.
Ez nagyon nem nyilván, ilyen típusú működésre a Windows szolgáltatások valók, nem egy random felhasználó nevében elindított exe.Ennek a helyi szervernek nincs nyitott portja a net felé, alapvető biztonság tehát megtéve. És nem is a 80-as portot használná a program.
A 80-as helyett másik port használata nem igazán számít biztonságnövelő tényezőnek.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz alratar #9095 üzenetére
Ha nem a fő projektnél szerepel az System.Data.SQLite.Core csomag direkt függőségként (hanem csak annak egy függőségénél), akkor tedd be oda is. Feleslegesnek tűnik, hiszen függőség függősége, azonban az olyan csomagoknál, amelyek tartalmaznak az output mappába szánt natív DLL-eket és ezt a másolást csomaghoz tartozó targets fájlban
CopyToOutputDirectory
propertyvel intézik el (és az System.Data.SQLite.Core így tesz, bár próbálkozik bizonyos esetekben direkt másolással is prebuild feltételként és postbuild eventben, biztosra akartak menni ...), ott ezek a natív DLL-ek lemaradnak a kimenetből akkor, ha az adott csomag nem direkt függősége a tényleges alkalmazásnak vagy webalkalmazásnak, hanem csak indirekt.Régen használtam már SQLite-ot és abból is a gyári csomagot, de valaha ezt duális DLL-lel oldották meg (lehet, hogy nem ez volt a neve, de valami ilyesmi), ami egyszerre tartalmazott natív részt benne az interop kóddal és managed részt a .NET felülettel. Úgy nézem, hogy változott azóta, a .NET Core a tippem a változtatás okára. Kár érte, mert ezzel pont ezt a függőségi szívást lehetett kikerülni.
[link]
Vagy használd a C# portját, és akkor biztosan nem lesz szívás natív DLL-ekkel.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Használj VS2017-et vagy VS2019-et és package reference-eket.
Így nem lesz
packages.config
, nem leszpackages
mappa, hanem a csproj fájlba kerülnek be a hivatkozások, a VS automatikusan proxy targets fájlokat generál a csomag hozzáadásakor/visszaállításakor, amelyek a%USERPROFILE%\.nuget\packages
mappa alatti fájlokat használja.Persze a lefordított projektekbe így is, úgy is bekerülnek a DLL-ek, szóval olyan sok helyet nem spórolsz meg, de időt a csomagfrissítéseknél rengeteget.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Bármi, aminek a támogatása nem igényel akkora bloatware-t sem a kliensen, sem a szerveren, mint a SOAP-é. Ha a legkönnyebb integráció a cél kliensoldalon, akkor JSON vagy sima form data, ha sok a bináris adat, akkor protobuf.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Szép dolog a szabvány, ha azt nem bonyolítják túl. A SOAP és a köré épülő infrastruktúra azonban túlbonyolított erőteljesen, ha pedig hozzácsapod a WS-Security-t, akkor főleg az lesz nem egyértelműen definiált elemekkel a szabványban. Szép dolog, amikor a Java és a C# világ nem tud beszélgetni egymással egy szabványos felületen keresztül úgy, hogy mindketten támogatják azt, mert adott feature X opcionális lehetősége közül sikerült diszjunkt halmazt implementálni (például bináris adatok hatékonyabb átvitelére a csak MTOM-ot támogató WCF találkozik egy csak SwA-t támogató Oracle alkalmazásszerverrel).
JSON, grpc (protobuf alatt ezt is értettem) eléggé támogatott minden platformon, az utóbbi esetben a túloldal megkapja a .proto fájlokat az interfészleírás részeként, és tud vele szépen dolgozni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz bandi0000 #9130 üzenetére
De most ez a megoldás nem rosszabb, mintha csak csinálnék pl egy osztályt, amibe van egy error és esetleg egy status code tulajdonság amit mindig visszaadok?
Ha kizárólag webes felületet nyújtasz, akkor szerintem ez az exception + middleware páros a legjobb.Ha vegyes felvágott a helyzet, mint nálunk, ahol webes és MQ felület is előfordul, akkor más a helyzet. Ezeknél az adott API implementációból az általad kérdezetthez hasonló üzenet jön ki, az API által dobható exceptionök kezelése belül megtörténik:
public class SomeResponse : IResponse
{
public string RequestID { get; set; }
public class OK : SomeResponse
{
public string SomeData { get; set; }
}
public class FailedBecauseOfThis : SomeResponse, IFault
{
public int Code { get; set; }
public string Message { get; set; }
}
public class FailedBecauseOfThat : SomeResponse, IFault
{
public int Code { get; set; }
public string Message { get; set; }
}
}Proto:
message SomeResponse {
string RequestID = 127;
oneof subtype {
SomeResponseOK OK = 1;
SomeResponseFailedBecauseOfThis FailedBecauseOfThis = 2;
SomeResponseFailedBecauseOfThat FailedBecauseOfThat = 3;
}
}
message SomeResponseOK {
string SomeData = 1;
}
message SomeResponseFailedBecauseOfThis {
int Code = 1;
string Message = 2;
}
message SomeResponseFailedBecauseOfThat {
int Code = 1;
string Message = 2;
}Sikeres válasz:
{
"some_data" : "data"
}Hibás válasz:
{
"code": 123,
"message": "blabla"
}Aztán ha MQ-n keresztül érkező kérésről van szó, akkor a teljes
SomeResponse
leszármazott megy vissza protobuf kódolással, ha webes kérésről van szó, akkor általában* egy réteg a hibákat a példány típusa és/vagy kód alapján megfelelő 4xx/5xx státuszkódokra mappeli és a hibaüzenetet tartalmazó JSON-t ad vissza, ha sikeres volt, akkor simán JSON megy vissza (webes kéréseknél aRequestID
sem kerül bele a válaszba, csak a konvertálást, szerializálást, naplózást befolyásoló attribútumokat az egyszerűség kedvéért lehagytam).* általában, mert volt, hogy a 200 azt jelentette csak, hogy a szerver válaszolt, és ugyanúgy protobuf ment vissza a kliens felé
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
-
dqdb
nagyúr
-
dqdb
nagyúr
Most nézem, hogy az első metódus a hozzászólásomban az
Add
helyettToConsole
lett volna, ha nem írom el ... szóval helyesen:public static class StringExtensions
{
public static void ToConsole(this string text)
{
Console.WriteLine(text);
}
}
public static class Test
{
public static string Add(string input)
{
return input;
}
}Az a lényeg, hogy te egy string példányon szeretnél saját metódust hívni, így a String osztályt kell saját metódussal bővítened. Az egész megoldás a syntactic sugar kategóriába tartozik mert ez:
Test.Add("blabla").ToConsole();
a háttérben valójában erre fordul le:
StringExtensions.ToConsole(Test.Add("blabla"))
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz DrojDtroll #9219 üzenetére
Ne a rendszerben található, .NET Frameworkhöz tartozó dll-t add hozzá referenciaként, hanem ezt a NuGet csomagot.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz Jokerpoker #9222 üzenetére
Project Properties > Build > Prefer 32-bit opció kikapcsolása, hogy lehetőleg 64 bites változat induljon el 64 bites OS-en a programból.
Azt azért megjegyezném, ha előre lehet tudni, hogy hatalmas fájlokkal lesz dolga az embernek, akkor feldolgozás megírásakor a legutolsó utáni dolog után jön csak pár lépéssel az a megoldás, hogy beolvassa a memóriába az egészet.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz alratar #9396 üzenetére
var date1 = DateTime.ParseExact("2020-11-26", "yyyy-MM-dd", CultureInfo.InvariantCulture);
Érdemes még a negyedik paraméterként átadni egy
DateTimeStyles
értéket is, amiben jelzed, hogy UTC-ről vagy helyi időről van szó.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Fegyencedzés - calisthenics - street-workout
- Kerékpárosok, bringások ide!
- Házimozi haladó szinten
- PlayStation 5
- Egységesíti a terméktámogatást az Intel?
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy S24 - nos, Exynos
- OLED TV topic
- Milyen okostelefont vegyek?
- További aktív témák...
- Toshiba KIOXIA XG8 4TB M.2 NVME PCI-E 4.0 x4 - Read-Write 7000-5800 MBs - Eladó!
- GAMER Intel i5 4570/ GTX 970 4GB / 12GB DDR3 / 120GB SSD / 250GB HDD / Beszámítás / Garancia
- ZBook Fury 16 G9 16" FHD+ IPS i7-12850HX RTX A2000 32GB 512GB NVMe ujjolv IR kam gar
- Lenovo M93P Tiny Micro - Mini PC - Core i5 4570T/8GB ram/256GB SSD - több db
- GAMER Intel I7 4790 / GTX 1060 6GB / 16GB DDR3 / 512GB SSD / Beszámítás / Garancia
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Ozeki Kft
Város: Debrecen