Develop Reference

How to get all app model based applications in SCCM without WMI?

With SCCM transitioning to APP model apps, instead of the original package model (appmodel vs packagemodel), I’m investigating how a legacy application built as a windows service using c# can interact with these app model applications. I would typically just use WMI operations to call the CCM_APPLICATION class, but the problem is this is a windows service running as system, so WMI is not really an option. Previously we got around this by using the UIResourcemgr DLL which offers us an interface to perform SCCM interactions. However this DLL is outdated and doesn’t seem to fetch the apps I need. So is there an updated DLL i can leverage to call app model apps much like The CCM_APPLICATION class would’ve gotten me or do I need to find a way to offload this work to the client side not the service side?

Difference between a console application and Web application in asp.net core

I am trying to run a background service which just writes to a file on a specified interval.
There are two methods that I tried
1) Created the project with the Console application template
2) Created the project with Web Application as template
When I run the app from visual Studio, both of them run fine. But when I deploy them to IIS, only the web application version works. It must be noted that there is absolutely no difference between the code of the two projects. I have used the WebHost as a hosting strategy in both the projects as well as well as installed all the dependencies in case of Console application as there are in the Web Application version.
I must also inform that I have used the preloadEnabled="true" option in IIS as IIS needs a web request to start the application.
I am wondering what is the difference between both the project types as the code is the same? I don't want the Web Application template.
Edit 1: I forgot to mention that the service will also need to expose an api endpoint for healthcheck purposes. Will the windows service approach listen for http requests?
I used the following article for implementing my background service.
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice

After years of building background services, I learned that Windows services are the best tools to implement these applications. While there are different techniques to keep an IIS application up and running in the background and prevent it from getting recycled, in practice, the applications on IIS are not meant to be executed forever.
If you had an intention to build your app in the cloud, I would have suggested using something like Azure WebJobs or Azure Functions Timer-Triggered functions, but for on-premise, even using something like Hangfire in the web is not sustainable. The worst happens when you need backward compatibility on Windows servers that don't have the "Application Initialization" module.
My suggestion is to move your application to a simple Windows Service if you control your environment. Windows services consume less memory, are easier to manage, and can run forever without getting recycled.

WebApplications are plain the wrong tools for this.
Being always on and always reachable, WebServers are primary targets for hacking. To compensate for that, they are usually run under the most restrictive user rights you can imagine: Read rights to their programm and this instances content directory. While I do not know why it worked at all, it propably will stop working in Production.
What you wanted to write was eitehr a Service or something executed by the Windows Task Sheduler. Personally I advise for the Task Sheduler as Services have their own set of restrictions. Unless of coruse there is some detail of the requirements that you did not told us.

This article could be helpful. It's a step by step tutorial on how to convert a console application to a web application.

Execute application on shared folder using resource of shared machine

I write small apps to help automate daily work of some colleagues and want to put on a shared folder on my machine so that others from local network can execute when my computer is on. I don't have the luxury of my own server so this is the best I can do.
One of which is a Winform app that connects to an Oracle database via an Oracle client and Oracle Data Access installed on MY machine to retrieve information. I would hope that people can execute the app (.exe file) when my machine is on, without installing anything on their machine. The app will write to an output file (.html) on the same folder and open it on THEIR browser.
My question is : What should I do to make it possible ? How can people run this .exe file using Oracle Client, Oracle DataAccess and .Net framework already installed on MY machine as if I am running it locally.
I mark all C# Assemblies (automatically added by Visual Studio) as Copy Local to True (Microsoft.CSharp.dll, System.Data.dll, System.dll, System.Data.DataSetExtensions.dll, System.Deployment.dll, System.Drawing.dll, System.Net.Http.dll, System.Windows.Forms.dll, System.Xml.dll, System.Xml.Linq.dll). Would people still need .Net framework installed ? My app is quite simple with only one external dll Oracle.DataAccess.dll. How about Oracle client and Oracle Data Access.
Many thanks.

Best solution for your situation is create a webservice and make the clients that'll consume your webservice instead of them making direct calls to your database. It removes system dependencies and easier maintenance.

Your colleagues can go to your computer via remote desktop if it is feasible. In the probable case that this is not feasible, you need to decide what the colleagues will see. If they only need to see the generated html and they only need to trigger the execution of your exe, then you will need to have a program which listens to a port and make sure that the given port is requested correctly by your colleagues via a small client app.
But honestly, the use-case you describe sounds like a website used by your colleagues. You can create a website in .NET, the exe you have would be the controller or code-behind depending on the approach you use and the HTML would be the response. Then the colleagues will just request your page with the port you are listening at.

Run c# code on client side or make a web session interactive?

I'm making an application on c# for signing PDFs. Its works perfectly on my visual studio web project, but when I publish it on my test server it throws me this Error
In this case I'm trying to execute the code that sign a pdf on the server and the error occurs specifically on the line:
System.Security.Cryptography.Pkcs.SignedCms.ComputeSignature()
It is supposed to throws a window on your desktop asking for your certificate (reading a smart Card) and then asking for your PIN just like this
Windows Security Window but I have the hunch that it's not possible because Its implies that the server have to have the possibility to interact with the client's desktop
Ok, now that I've explained all the enviroment that I'm facing, here are the solutions I've tried until now:
1) Trying to correct the Server Error above: I went in the server to IIS>application Pool>MyPage>Advanced Settings>Process Model>Load User Profile and selected True instead of False (Didn't Work)
2) Still trying to correct the Server Error I Went to Computer Management>Services and Application>Services and turned on the service "Interactive Service Detection" (Still not working and doesn't work even if I do the same on the client computer)
3)Finally, I guess that it's not possible to run the code on the server because the Error line above is a native calling of Windows Security so I thought: what if I try to run the code right from the client?. Like a c# applet equivalent or something, well... there are two ways for do that: ActiveX (old technology) and Silverlight (newer). The thing is that I just can't make a simple Silverlight program start on chrome, it does on firefox and IE but if doesn't work on chrome is a totally waste so my last option is to make it run with an ActiveX, and there is almost none useful information in the internet about that
If someone can tell me what to do, either to correct the error or to make my program run from the client side, I would be so grateful

You can't call the system's api from a Web client as this would break the sandbox. If you must use that system call, create a wrapper on the server that will handle the popup, although this would be a very "hacky" solution. You should really be asking why I am trying to use a Web client interface if I must use said native system call.

Local or remote programmatic execution of an SSIS package?

I have an SSIS package on my desktop, which I registered to Integration Services on a remote box.
The service I am going to use to execute the SSIS package I have registered on that box will be hosted on an app server else where in the network and will be making a call to execute the package.
Before I begin writing the final code to make this happen, I have come to a fork in the road on how to proceed:
MSDN has two articles on how to programatically access an SSIS package.
One article is titled: Running an SSIS Package Programmatically on a Remote Computer
The other article is titled: Running an SSIS Package Programmatically on a Local Computer
I have read both, but its confusing to me how they are using the terms Local and Remote. \
It seems the Local Article says that even if you have a package on another computer, with this implementation it gets run on your local machine.
With the Remote Article it seems like the package will only execute if the service that calls it is running on the same machine. To me, this seems like a true "local" implementation.
Which article / implementation would I need to follow in order execute a package as I described above?
Again, I am running a Windows Service on my workstation and trying to execute a package that is registered on another. To me, this seems to be the Remote route, but I don't know.
Help! Thanks.

Yes, you are right, it's a little bit confusing. You should read this blog entry as well. Michael Entin posted a whole bunch of opportunities. He is focusing on the local/remote execution ways of running packages.
However, there is another way, through PowerShell.
In your case, I think it will not be good if you implement a web service on the application server. If you use SMO in this web service, the package will executed on the same server, which don't have SSIS installed, I guess. So this will fail. If you install your web service on database server, it'll be ok. But this way, you should open a specific port on this server. (Ok, I know if you implement the PowerShell way, there two ports have to be opened.)
Update
I try to explain on a little example. Say you developed a WinForms application in which you have a task that will launch an SSIS package. You installed this app on your application server. There is another server with SQL Server (and SSIS also) installed. This is your database server. When we talk about local/remote package execution we watch the system from the point of view of the WinForms app. Because the SSIS component is installed on the remote server (i.e. database server), you can only use the remote execution. So your windows service should be implemented on the database server. Another question might be how to reach this windows service. In the remote execution article you previously mentioned are two different ways of implementing remote execution: through SQL Server Agent job, and through a web service. The third option would be PowerShell as I mentioned above.
Of course from the point of view of the job or web service it is a true local implementation, as you wrote. But the MSDN articles focuses on your application on your application server (WinForms app for instance).