Microsoft .NET Framework Reviews

For development, we focus on specific projects.

We are an IoT company specializing in innovative solutions.

I don't know much about it as it's a development framework. We use it as it's a good language, a good environment with fairly good performance.

It's part of the Microsoft .NET Framework environment. Microsoft .NET Framework runs under the CLR, the same as Java runs under the Java virtual machine.

It's a rich library that helps with development. It's a good environment with many features and many libraries that help developers work quickly and efficiently. Since I'm using a very old version, there isn't much to add.

It's flexible, but since it's an old version of Microsoft .NET Framework, there are some limitations. As long as it can run on Windows, it's acceptable. The limitations are due to its very old version.

Some cloud features will not run in an old version of Microsoft .NET Framework easily or at all. Running on the cloud is complex. The support for a cloud environment, not as a virtual machine but, for example, in Azure App Services, proved challenging. I tried running a web application but couldn't make it work, although technically it should be possible. To run an older version, I had to make adjustments in the running environment, but ultimately couldn't get it to work. There's no support out of the box for older or very old versions.

The new Microsoft .NET Framework runs perfectly in the cloud without problems. This review concerns a very, very old version.

I get information from different endpoints as an aggregator. From that point, we create different map responses to create different information that we will use in different micro-frontend applications. It has different micro-frontends, similar to Jira with various widgets that receive responses from specific endpoints to display on the dashboard.

I have not been working with AWS technologies for a month, but it was the last cloud platform I worked with.

I worked with Elastic Search and Grafana. It was for tracking purposes, specifically with Kibana.

I primarily used ECS, databases with RDS, S3, common services, queues, and Elastic Search, though Elastic Search is not specifically AWS.

We started working mostly with Microsoft Visual Studio because we had services that we deployed directly on Azure. It was a small amount of microservices that we were publishing. The idea was that we did not want to use Visual Studio proper, rather than Visual Studio Code, for working because it was too heavy for the developers.

The structure that can be created is beneficial because once you have the structure, you can be more productive and faster to create and interact with different clouds and implementations. It should be something that costs more at the beginning, but becomes easier once the foundation is established. The first part of the project always takes considerable time, and the structure needed inside the company can be challenging initially.

We have been using it because it helps manage all the threads for each system and lines of business that need to be implemented or consumed. This provides a standardized project. Depending on how you structure the project, if you only have microservices without shared CLS, it could be problematic. However, with a segregated domain, you can leverage it in different APIs or endpoints. You have the same domain in different places. You can also put different responses in the response part, while the whole domain continues having the proper structure from the database if using an ORM. It depends on how you use it and want to use it.

A team of developers in our organization are using the solution. Microsoft .NET Framework is used in our company for web and mobile application development. 

The solution has assisted our organization in the full-stack development process. The tool can be deployed on all types of devices, including mobiles and desktops. The MAUI capabilities of the solution have been the most beneficial feature for our organization's development needs.

At our company, we never had the option to develop for external users. By using specific frameworks from the solution or MAUI, our company has been able to develop mobile apps that can be deployed externally with utmost security. 

The product exhibits impressive compatibility. In our company, the solution is being integrated seamlessly with iSeries, K2 Environment and all vital databases where the data is stored in Db2 and SQL. 

I use Azure DevOps because we have everything implemented in .NET by Microsoft, and we are integrated with the collection of the requirements, the .NET pipeline, and directing Azure DevOps for Azure Plus. I am more of a developer, so from an infrastructure point of view, I do not have feedback or experiences to share. I use it more for requirement documentation. For historical reasons, our product was born in .NET.

For us, it is better to remain under the umbrella of Microsoft.

We use Microsoft .NET Framework to develop Windows applications. It is utilized for Windows form solutions to create Windows-based applications. Our team uses it in our software development process for data connectivity, user input form validation, user management, authentication, and authorization.

It is beneficial for running smooth operations on every application. We face minimal problems using it, allowing for stable and efficient operations.

We use the solution for some internal applications we develop. We also use the Microsoft workflow engine.

When using Microsoft .NET Framework, you start writing the code internally. This reduces the cost on the licensing side, which helps reduce the overall expenditure of OpEx and CapEx.

As an architect, I figure out the best solution based on the problem at hand. It doesn't always have to be a website. Sometimes a hybrid solution is needed – one solution that can be ported to mobile or websites. I want to avoid having two different sets of code that need changes in two places. My goal is to make it as generic as possible.

So, I stay updated with the current .NET Framework and try to come up with a hands-on architecture. I develop those centric modules and provide libraries to our developers, which they add as project references. I call them the organization's libraries. This way, everything follows the same design principles.

For instance, if I create a website using the MVC framework, it has to be consistent. If I need architecture on top of it, I would use screen architecture. Then, there are other architecture and design types. If I need to write a Windows application, I prefer WPF (Windows Presentation Foundation) with the MVVM framework.

We pick and choose what's needed based on complexity, data volume, storage, etc. Would the architecture be three-tier, service-oriented, or domain-driven? You break things up into database, API, and front end. Recently, I've introduced gateways for security, which have their own design pattern. I'm trying to move from API to microservices – it's about staying up-to-date and educating the team and managers.

ASP.NET within the .NET Framework improved our development process.

With the old ASP.NET, if you were using web pages, you had the traditional page lifecycle. The introduction of MVC changed things – they're two different lifecycle methodologies. 

MVC is lighter, faster, and easier to implement, while the old way goes through its own page lifecycle before rendering, which is a bit slower, in my opinion. 

Now, with .NET Core, you get out-of-the-box stylesheets like Bootstrap and more of a boilerplate setup. It's much easier – before, you had to build everything yourself. Now, with the .NET CLI (Command Line Interface), development has become even simpler.

I'm a developer with .NET Framework. Apart from powering the Xamarin platform, I also use .NET for API development for .NET Core, which I deploy on clouds like Azure or AWS. We use .NET Core for every solution, from built-in web apps to REST APIs. I can use .NET Framework to build desktop-based applications using a company called WPF. We use .NET for Unity, a popular gaming engine. It uses .NET as well as C#. In our organization, we just use .NET for Xamarin.

Given that it's cross-platform right now, where you can use it on Windows and Mac, that is the single most significant feature that has resulted in wider adoption of .NET. Earlier, you could only build solutions for Windows and Windows server ecosystems, but now you can build a .NET Core app and deploy it on Linux VMs, and so on.