• Du befindest Dich hier:
• Community
• »
• Mitglieder
• »
• Abt
• »
• Beiträge von Abt

DevOps ist ein Prozess und kein Tool.
Eigentlich jede Software lässt sich automatisiert im Build umsetzen. Hab das auch schon mit Ansi C für Controller gemacht.

Spätestens wenn man beachtet, dass man mindestens 10 Jahre jede Software und jedes Artefakt, wozu eine Firmware gehört, rechtlich aufbewahren muss, ist der Aufwand eines solchen Prozesses ein Vielfaches geringer - einfach weil es dafür standardisierte Wege gibt, die solche Vorgaben beachten.
So wusstest du davon vermutlich gar nichts und erfüllt vielleicht daher auch nicht diese Vorgabe :-)

Aber ja bei DevOps ist das leider wie bei der IT Security, nur dass du bei DevOos mit einem kleinen Invest sehr viel Arbeit in der Zukunft sparen kannst. So hast du ein Tool dass meistens über die Zeit mehr Geld und Aufwand kostet als wenn du Standardmittel verwendet hättest.
Blinde Augen und taube Ohren: Es gibt immer das Budget vor einem Security Leak und nach einem Security Leak.

Also Deine ungarischen Notation tut in den Augen echt weh, da muss man Palladin recht geben...

File.CreateText(Path.Combine("D:\S7_Export\AppData\" , strFolder , strDummy[i])

using (StreamWriter myWriter = File.CreateText(@"D:\S7_Export\AppData\" + strFolder + strDummy[i]))
{
    myWriter.Close();
}

using (File.Create(filename)) ;
// oder 
File.Create(filename).Dispose();
// oder 
File.WriteAllText(filename, String.Empty);

Path.Combine(Job1, ext);

Bin mir nicht sicher, ob Blogposts für sich extra Themen wert sind - aber nun ja...

Dass solche Gens jetzt vermehrt kommen werden, war ja im Endeffekt durch Source Generators klar.
Siehe auch sein tweet mit den entsprechenden Kommentaren dazu.

Die Fritzbox is halt leider eher so nen Heimspielzeug, auf der Du nich viel konfigurieren kannst.
Mächtigere Systeme wie zB. das UniFi Zeug synchen Deine IP periodisch, sodass Du keinen Reconnect-Trigger benötigst.
Auch das VPN der Fritzbox kann man kaum ernst nehmen, obwohl zumindest die App eingiermaßen komfortabel ist.

Bei mir is die Fritzbox vom Provider auch nur der Connection Gateway; alles dahinter gescheite UniFi Hardware.
IIRC bleibt Dir hier mit der Fritzbox kaum was anderes als nen externes Tool oder die Provider-Fritzbox zu verwenden.

..und für sowas nutzt man eigentlich ein Release System wie zB Azure DevOps :-)

Das Buildsystem erzeugt die Software und packt daraus ein Artefakt (zB Deine ZIP).
Das Release System stellt diese ZIP dann entsprechend zur Verfügung, zB auf einer Share oder einem anderen Storage.

Komme auch aus dem Maschinenbau und berate Maschinenbaufirmen seit vielen vielen Jahren solche Prozesse zu standardisieren und gerade zu ziehen :-)

Bis auf dass man Pfade nicht mit String Frickerleien zusammen baut, sondern mit Path.Combine ist das ok.
Deswegen kann es gut sein, dass Du einfach in die Fakten meines Beitrags läuft. Da hilft leider nur ein Delay.
Gibt aber leider keinen fixen Wert für einen Delay, da dies auf das OS und die Hardware/Systemauslastung ankommt bzw. unterschiedlich ist.

Kann das sein, dass Du hier etwas baust, das eigentlich ein Release System automatisch machen sollte..?
Frage nur wegen den Bezeichnern.

So schnell wie Du geantwortet hast, kannst ja nich wirklich gesucht haben ;-)

Google Suche nach "innosetup Trojan:Script ico"
Erster Treffer -> inno setup executable seen as a Virus

Installer Platformen und nicht signierte Software (-> Microsoft Signcode) lösen sowas gern aus.
Bei InnoSetup hab ich schon oft gelesen, dass es am Ico liegen kann.

Als Hinweis für die Mikro-Optimierer: die "vereinfachte" Schreibweise ist i.d.R. nicht die schnellste.
.Where(predicate).First() ist schneller und erzeugt weniger Allocations als .First(predicate); das gilt für alle Anwendungen von .Where().
Hintergrund ist (vereinfacht), dass zB First() auf einer Schleifen-Implementierung basiert und .Where() auf die Iteratoren der Collections zurück greift.

Hier ein Benchmark Beispiel:

public class LinqTest
{
    private List<string> _list;

    [GlobalSetup]
    public void Setup()
    {
        _list = Enumerable.Range(0, 100).Select(c => c.ToString()).ToList();
    }

    [Benchmark]
    public int WherePredicate() => _list.Where(e => e.Contains("a")).Count();

    [Benchmark]
    public int CountPredicate() => _list.Count(e => e.Contains("a"));
}

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
.NET Core SDK=5.0.300-preview.21180.15

|         Method |       Mean |    Error |   StdDev |
|--------------- |-----------:|---------:|---------:|
| WherePredicate |   504.7 ns | 11.90 ns | 11.13 ns |
| CountPredicate | 1,166.8 ns | 11.30 ns | 10.57 ns |

Was genau hast Du vor?

In WPF arbeitet man eigentlich nicht primär mit Events. WPF ist so konzipiert, dass der MVVM Pattern verwendet werden sollte.
[Artikel] MVVM und DataBinding

Mit der Informationen an Anforderungen, die Du hier nennst, kommen hunderte von potentiellen Lösungen in Frage.
Die einfachste ist natürlich HTTP.

[FAQ] Variablennamen zur Laufzeit zusammensetzen / Dynamisches Erzeugen von Controls

In Deinem Fall riecht es aber eher danach, dass Du einen Event für alle Controls verwenden kannst und daher der Wunsch nach der Laufzeiterzeugung eher ein Denkfehler ist.

Wir hatten schon tausende Beiträge zum Webbrowser-Control. Dieses ist völlig veraltet und basiert im Standardfall auf dem IE7.
Alternativen sind seit vielen vielen Jahren https://github.com/cefsharp/CefSharp bzw. Microsoft Edge WebView2-Steuerelement - Microsoft Edge Development
Einfach mal 10 Sekunden die Forensuche verwenden ;-)

Weil das ein Krampf ist, was Du da zusammen puzzlest, wenn man Dir das direkt sagen darf.
Directory.GetCurrentDirectory() ist in allen Aspekten der falsche Weg. Keine Ahnung, wie Du darauf kommst. Vermutlich irgendwo mit einem anderen Zusammenhang her kopiert?

Beachtest Du meine Beiträge dann kommt das bei raus:

RazorLightEngine engine = new RazorLightEngineBuilder()
    .SetOperatingAssembly(Assembly.GetExecutingAssembly())
    .UseFileSystemProject(executionContext.FunctionAppDirectory)
    .UseMemoryCachingProvider()
    .Build();

TestViewModel vm = new TestViewModel();
string result = await engine.CompileRenderAsync("Views/Test.cshtml", vm);

  <ItemGroup>
    <Content Include="Views\Test.cshtml">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

public class Function1
{
    [FunctionName("Function1")]
    public async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req,
        ExecutionContext executionContext)
    {
        RazorLightEngine engine = new RazorLightEngineBuilder()
            .SetOperatingAssembly(Assembly.GetExecutingAssembly())
            .UseFileSystemProject(executionContext.FunctionAppDirectory)
            .UseMemoryCachingProvider()
            .Build();

        TestViewModel vm = new TestViewModel();
        string result = await engine.CompileRenderAsync("Views/Test.cshtml", vm);

        return new OkObjectResult(result);
    }
}

Siehe Dokumentation von RazorLight:

1) Templating Directory mit relativem! Pfad. Den bekommst Du über den Function Context.

string path = $"{ context.FunctionAppDirectory }/MyTemplates";
UseFilesystemProject(path)

RazorLight funktioniert einwandfrei in Functions; verwende ich auch.

PS: interessant, wie wir von Logging über Dependency Injection mittlerweile bei RazorLight angekommen sind, nur weil Du Deinen Code zu sehr verfremdelt hast.
Das kostet nicht nur Dich Zeit, sondern auch Helfern ;-)

Zum Problem:
Das Erzeugen von Tabs im Code Behind ist eigentlich kein Non-Plus-Ultra, sondern verletzt eigentlich die Binding-Idee von WPF und MVVM.
Bedeutet: Du solltest primär den Binding Weg gehen und Code-Behind wenn möglich ganz weg lassen.

Bei Tabs hat i.d.R. jeder Tab sein eigenes ViewModel und entsprechende Inhalte.
Das Window selbst ist ebenfalls ein ViewModel, wie auch das Tab Control. Ergo: ein ViewModel kennt seine Child-ViewModels.

Hinweise zu Deinem Text:

Ich hab mir kurz 2 Minuten Zeit genommen, hab das Standard Visual Studio Template genommen und ein Function Projekt angelegt.
Hab es konfiguriert, wie es in Verwenden der Abhängigkeitsinjektion in Azure Functions (.NET) beschrieben ist; hab Dein Code reinkopiert (und die Syntaxfehler beheben müssen...).

using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using MyNamespace;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]
namespace MyNamespace
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddTransient<IMyService, MeinService>();
        }
    }

    public interface IMyService
    {
        Task Do();
    }

    public class MeinService : IMyService
    {
        private readonly ILogger<MeinService> _logger;

        public MeinService(ILogger<MeinService> logger)
        {
            this._logger = logger;
        }

        public Task Do()
        {
            _logger.LogInformation("Test");
            return Task.CompletedTask;
        }

    }
}

namespace FunctionApp1
{
    public class Function1
    {
        private readonly IMyService _myService;
        private readonly ILogger<Function1> _log;

        public Function1(IMyService myService, ILogger<Function1> log)
        {
            _myService = myService;
            _log = log;
        }

        [FunctionName("Function1")]
        public async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req)
        {
            _log.LogInformation("C# HTTP trigger function processed a request.");

            await _myService.Do();

            return new OkObjectResult("Works");
        }
    }
}

Publishen hat mit Dependency Injection nichts zutun.
Dass nen neues Projekt funktioniert, da spricht es dafür, dass Deine Pakete nicht aktuell sind oder was anderes krum ist, zB. Runtime Version.

Dann kommt das entweder vom verfremdeln Deines Codes, was mein Missverständnis auslöst, oder Du hast ein ganz kurioses Klassen/Namespace Design...

// Dieser Zeile nach befinde sich die Startup Class im Function Namespace
[assembly: FunctionsStartup(typeof(Function.Startup))]

=> Function.Startup
public class Startup : FunctionsStartup

// Die Function hat aber gleichzeitig den Klassenname Function
public class Function

Du verfremdelst Deinen Code ein bisschen zu sehr, wenn ich Dir das sagen darf.
Dein Code kann niemals funktionieren, weil offenbar laut dem Beispielcode hier Dein Namespace und Deine Function beides Function heissen - das kann nicht sein.
Kannst bitte Dein Code nicht ganz so sehr verfremdeln, oder zumindest sinnvoller?

Rein von der Registrierung hier sehe ich keinen Fehler. Das Transient vs. Scoped macht hier keinen Unterschied.
Sind Deine NuGet Pakete auch wirklich aktuell und bist auch auf der aktuellen Function Runtime?

Hat Dein MainService noch irgendwelche Abhängigkeiten, die nicht aufgelöst werden können?

Du kannst Sqlite so verwenden, dass Daten auf die Disk geschrieben werden (local file) oder aber nur im Speicher gehalten werden (in memory).
Ersteres ist persistentes Speichern, zweites zB. nur für Caching oder Tests - Daten gehen verloren, sobald der Prozess zuende ist.

Das doofe ist, dass Dein Try and Error Vorgehen hier nicht helfen wird.
async/await ist leider ein Konzept, das man verstehen muss. Sonst wendet man es - wie hier - in 99% der Fälle falsch an.

Du musst auch nicht die Schleife asynchron auslagern, sondern das GetProcesses.

private static Task<Process[]> InternalGetProcessesAsync()
    => Task.Run(Process.GetProcesses);

In meinen Augen machst Du Dir das Leben selbst schwer, aber musst selbst wissen.

Verwende einfach die Isolated Process Variante, registrier Dein Serilog, setz Application Insights direkt als Sink -> fertig.
Ich verwend das seit dem ersten Tag der Isolated Process Möglichkeit in hunderten von Functions, super einfach und endlich muss man die Besonderheiten der Function nicht mehr beachten.
Musst für Serilog 2 Pakete einbinden, die Config setzen und eine Zeile Code einfügen.

Mit ILogger hat das nichts zutun, denn ILogger ist nur das Logging Interface, das eigentlich alle Logging Implementierungen verwenden. Das Kernstück hierzu ist die LoggerFactory.
Willst Du Serilog nicht nutzen - warum auch immer - dann kannst entweder das AI SDK selbst implementieren oder eben direkt auf die Console schreiben, das dann wieder im AI Log landet, weil das die Runtime automatisch macht, wenn die Umgebungsvariable gesetzt ist - alles soweit in meinem ersten Beitrag erwähnt.