I've inherited an application, whose origins are lost in the mists of time. It's fairly obvious, based on DLL references and database tables, that the application is based on some edition / variant of ASP.NET Boilerplate. The question is exactly which one? The possibilities (I know of) are:
ASP.NET Boilerplate (free, open source)
ABP Framework (free, open
source)
ASP.NET Zero (licensed, source provided)
ABP Commercial
(licensed, source provided)
Whatever I have, it's obviously an old version since it's running on .NET Framework. (Latest versions of all of these application frameworks run on .NET Core.) We are working toward a phased transition to .NET Framework on .NET Core but one of the first things I picked up on is the incompatibility of my existing database structures for account authentication with the latest ABP Framework. One of the prerequisites for a phased transition is that a single database repository should accommodate account authentication from both the legacy system (as it does today) and the new system we are going to start constructing. I'd like to start working on various alternatives to bridge the gap from "here" to "there" but I'm handicapped by not even knowing where "here" is. I do know that the existing application is based on some variant of ASP.NET Boilerplate, but there are at least four of those. If you can help me pinpoint exactly what I've got, that will be immensely helpful. Thanks!
(All application ABP references are to DLLS. We don't have any ABP source code which might be useful for identification purposes.)
Here is a snapshot of the database tables, if that helps to make the identification:
Here is the one row within the abpEditions table:
Packages with the Abp prefix belong to ASP.NET Boilerplate or ASP.NET Zero. Packages with the Volo.Abp prefix belong to the ABP Framework or ABP Commercial. Since you have the Abp.Zero package, it appears to belong to ASP.NET Zero. The version information also appears to be 4.0.
Related
I have a mvc application which I do not want to change. I also want to create an asp.net core web application with angular. I also have a ms sql database with and ado.net/edmx project.
Know I want to get my users, stored in the database. How can I reference my database project?
I have tried creating a new EF project with database first but that means changing other applications as well.
This is already a supported scenario. The only condition is that your ASP.NET Core project must target .NET Framework instead of .NET Core. See: https://learn.microsoft.com/en-us/aspnet/core/data/entity-framework-6?view=aspnetcore-2.2. For what it's worth, .NET Core 3.0 will support EF 6 natively, so eventually, you'll be able to target .NET Core again, if you choose this path.
Short of that, you should be able to create an EF Core library to work with your existing database which your ASP.NET Core project can then utilize. Since it's referencing the same database and not making any direct alterations to the schema, it should have no bearing on any other applications.
I have created an .msi installer. I want to further add prerequisites (such as .Net) but when I go to Setup Project properties, the Prerequisites button is disabled. How do I enable it?
Other details:
I'm using VS 2015, SQL Server 2008 R2, .Net 4.5.2, C#, WinForms, Win
10 Pro x64
My setup project is in the same solution as the main project
Prerequisities in Visual Studio Projects
In Configuration at the top of the dialog, did you try to select either Release or Debug? That should enable the Prerequisites... button.
Unecessary, outdated prerequisites?
One pet-peeve of mine: is it really necessary to include the .NET runtime as a prerequisite when most users have it installed by their deployment team (corporations) or via Windows Update (home and small office users)?
If there are security updates for the runtime, your old, embedded runtime is just a nuisance to be honest. Corporate packagers spend a great deal of time removing runtimes and prerequisites for corporate deployment where all runtime components are packaged separately in the corporate standard format. Perhaps consider making a special corporate "large scale deployment" version of your setup bundle? Just a zip with components will be very appreciated, along with a one page PDF on how to deploy them.
For the .NET framework you could just add a launch condition to abort the installation if the runtime is not found, and tell the user to get the runtime via Windows Update or from their system administrator or deployment team.
Just a thought I wanted to share with you. Prerequisites can really bloat a setup - especially when they are almost never needed like the .NET framework. In the future we will certainly pull prerequisite packages straight from online repositories and not embed anything in our main setups (and probably struggle with new security issues from that approach).
What version of the .NET Framework is included in what version of the OS?
Selectively disable versions of the .NET Framework (.NET versions overwrite each other)
WiX and other deployment technologies
Setup projects are rather limited. If you find yourself needing more features, you might want to check out the WiX toolkit.
Here is a previous answer on WiX and other deployment tools that seems to have been helpful for people: MSI vs nuget packages: which are is better for continuous delivery?
The company i work for has a application developed in the 90's in Delphi for managing employees. Because the company has no delphi developers available i was assigned to develop it in C#/WPF using the mvvm pattern.
After 5 months of development, the .NET version had the same functionality as the old application, with less bugs and some nice additions. So i tagged the release, got it tested in my department and send it to the other departments in other locations....
And then i got a email from the CEO with the frightning question: How does this work on my MAC?
Apparently the product owner was forgotten to mention that only our department worked with Windows PC's and all other departments worked with Mac PC's. The old delphi application worked under Winebottler at these departments and the product owner thought this was no problem for the .NET application.
When you look at different websites, you can see it could work using Winebottler, but this is not guarenteed. And ofcourse after wrapping it in Whinebottler, it did not work. I have no MAC PC, so i need to send the code to a colleage in another department (and city) so he can bottle it and see if the changes work.
So my question is, what libraries/practices do I need to avoid when develop a application?
The following things i have researched:
It only works for 32bit applications
My version of .NET is supported (And included in the prefix)
Mono or .NET Core does not work because WPF are not supported in these applications.
The following practises i'm not sure if they could break Winebottler:
Using Environment.SpecialFolder
Starting processes with Process.Start()
Print with DymoPrinter labels
Wix Toolset Installer
MySQL.Data (MySql .NET Connector)
Nlog
So my question is, is there somewhere best practices to develop a .net application for winebottler and libraries/functionality to avoid?
Or else, tips to make my application to work on Mac.
How about GTK#?
The Gtk# installer for the .NET Framework gives .NET developers all of the pieces they need to build and run Gtk#-based applications, the same set of libraries that are used to build Unix applications on Mono.
http://www.mono-project.com/docs/gui/gtksharp/installer-for-net-framework/
The company I am working in has a ClickOnce application built using .NET 2.0 CAB framework.
As part of the technology refresh cycle the hardware and softwares are being upgraded.
The decision is to migrate the ClickOnce application from .NET 2.0 to 4.5. As mentioned above it is built using the CAB framework.
From googling and reading items from the internet, I concluded the way forward is to migrate to WPF - PRISM framework.
I have some questions that I am not able to get clear answers.
What is the complexity of undertaking such a migration?
Would it involve rewriting the entire application, reusing parts of the code like business layer and data layer?
Alternatively would it make sense to leave the application as it is and only rebuild it targeting the .NET 4.5 framework and fixing errors due to deprecated components?
Background: I developed a small .NET 3.5 WPF application that connects to an Oracle 9i database. Thinking that the ODP.NET version had to match the database, I downloaded and used an [older version][1] (9i, release 2, to be more specific) of the Oracle Data Access tools.
I'm basically done the application now and need to deploy it. Then I looked at the deployment story for ODP.NET, thinking it would be included as a prerequisite by ClickOnce and I wouldn't have to do anything. Lesson. Learned.
Everything I've read about deployment for ODP.NET talks about using XCOPY with a newer version of the Oracle tools than what I have used to this point. Not much is actually said about 9i in the documentation I've read to this point.
So what should I do?
Thanks for the help!
Here is a similar post where the answer was to change to use a 3rd party library:
ODP.NET and ClickOnce possible?
I think you area in trouble as changing libraries may involve you doing a full retest of your application - this may of course be easier done than said if it is a small app or you have good automated test coverage. Of course it depends how many computers you are deploying to. Personally I would be more inclined to stick with oracle odp and move to the latest version. If you deploy odp "the hard way" you still get the benefit of click once for future redeployments.