We have numerous small applications in our organization, most of them .NET web applications. Each of these has a seperate authorization system.
I would like to create 1 library of functions to do authorization checks to use in all these applications.
I would like to have this library centralized, so that if i want to make changes to it, i don't have to go in each application seperatly and update the reference.
What would be a good way of doing this, or should I take a different approach?
PS: Since I will be looking to use this concept also for other situations, I'm not looking for authorization specific solutions.
Don't do this.
Everything will be fine for ages, and then an error will creep in and all your sites will go down at once. Instead look at automating your build, test and deploy cycle with tools like TeamCity, NUnit and OctopusDeploy that so that you can regression test each and every app, then deploy the new tested package (i.e. web site + security dll) quickly and easily.
The way I would do this is to pull your library out into a separate dll and start using in one application (I'll assume this is of course fully unit tested :-) ). Next use NuGet to build yourself a package containing the dll. You can host the Nuget package (just put it on a share to start with) and then re-use it all your other applications.
Related
Multiple Asp.Net Framework 4.6.2 MVC/Razor projects within a single solution.
They use Areas, and each project will implement one or more Areas, distinct from the other.
One project acts as the "primary", and includes the global.asax.
The "subordinate" apps can know about the "primary", but not vice versa.
Is it possible to deploy these to the same web site? (on-prem VM).
There would be some collisions, such as the _Layout.cshtml.
Some how I'd have to be able to setup dependency injections for the classes in the "subordinate" project assembly.
Thanks
-John
I don't think this is possible easily, because so much of an MVC site is pre-compiled into DLLs, and yet some of it (e.g. view files) must be actually physically deployed outside the DLL. You are likely to run into conflicts or confusion I think. It's certainly not a reliable, definable process that you could count on in production.
Here are some alternative suggestions to solve the underlying problem, based on what you described in the comments. These are just ideas, some of which I've done or seen done, and might not suit you, but any of them should be a lot easier to manage than trying to bodge the deployment process:
1) Try building the areas in separate projects as you do now, but without all the generic MVC stuff that surrounds it. I.e. Do it as if they were libraries only containing the files specific to their functionality. Then you can package them up as Nuget packages. When they're ready, install the packages into the "main" site to create the combined solution. That way you won't run into conflicts of layout pages etc. If one of the sub-projects changes, then the main site can just upgrade the NuGet package. You can create private NuGet feeds either via Visual Studio Online (if you have a subscription) or on the simplest level via a shared network folder. I think other online vendors offer private feeds as well. We've done that quite successfully to apply some default styles, scripts, layouts etc to all our various MVC apps.
2) Re-architect your solution as a series of separate apps (that's the bit you've already got), but with a central service that provides federated authentication/authorisation (e.g. ADFS, IdentityServer or similar), and a web API (or APIs) that the other sites can call to access other centralised services and functions programatically. I'm pretty confident you can use routing config and shared sessions to make it all hang together as if it was actually one site.
3) Build it all out as just one site, but with clear separation for the various teams about the back-end services, classes etc that they are responsible for, so they don't interfere with each other's code. Each team can check-in code to different branches in source control and only merge to the shared branches for integration/system testing and deployment. You can use a continuous integration server to test the build process after each check-in, and if you have robust code review and gated check-ins you can stop people changing stuff that they shouldn't. You also have the flexibility to release with/without updates from the various areas, if the development lifecycles are going at different speeds.
4) Some combination of all of the above!
We have several different applications built in ASP.NET that run different parts of the same platform. I.e. An administration web app, a public facing web app and some non-web applications (I.e. .exe apps) that all need to perform some shared functionality.
Ideally I don't want to clone the code due to maintainability issues. Until recent we had all these running on the same server so we could just put some DLLs in the global assembly cache (although we never got around to this and did end up with cloned code).
Now we've moved the various parts of the system to separate servers, putting shared code in the GAC won't solve the cloned code issue. Is there a way to share code across multiple servers without making copies?
You want to perform a distributed execution, because you want to launch and executable in a different machine, and this is probably easily feasible doing a shared folder (but you should be really careful about security).
Another solution is to create a web service that exposes a method to launch the executable or run the task you want to share. In this way you have only one place to update the code.
I can think of three options:
A single solution which contains several projects, including another project containing the platform.
Having the platform/engine on a different solution and share the dll with each project (you have to update each time).
Provide an API which is shared with all projects.
Are you guys already connected to TeamExplorer? Assuming your IDE has it. Otherwise try to publish the code to the same server.
Do you have one solution with the web application project, class libraries, database project and tests? Or, do you segment it into multiple solutions? Why?
I'm asking because we're trying to streamline this scenario for Visual Studio 2010 and I'd like to get input from the community on how you'd prefer to work.
I tend (but not always) to have one solution per job, but I import existings projects from other solutions, such as my WebControlLibrary where I keep common user controls and classes, etc.
My actual solution for the job I then tend to break down into the Web Application, Business Logic Layer, Data Access Layer and Entity Layer, i.e.:
Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment
If a project requires something such as a mobile device, I'll always put that in a new solution, but it may perhaps share some projects of the current solution, i.e.
MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic
The more 'stuff' you have combined, the slower Visual Studios becomes at building. You can obviously stop certain projects building by default, but that's when you have to start creating your own build configurations. If you are going to be creating large applications, I'd suggest breaking down into multiple solutions. I find it much easier to flick between solutions that to keep changing build configurations.
Another option is that when you build your projects you can reference their DLLs. I prefer to import said projects into my solution as you never have to worry about referencing the creating build configuration i.e. selecting the DLL from the Debug or Release folder.
Stand alone libraries can be their own solutions. References for those libraries can be made into the project that you're working with. Related items like the web application, the test setups, and specific libraries such as data access or business rules can be setup as projects within one solution. It really all comes down to how much you want to break things out for resuability.
This depends a little on the job the project performs.
For ease of use it's simple to have a solution that just contains all the projects required. If it's a large solution this can hamper you later on when the IDE starts to get slow and build times rocket through the roof.
Let's say one of the projects is a library used by your company to take card payments and interface with 3d secure. You present you're own GUI page to take the details etc.
If you had numerous sites that all take card payments you would greatly benefit by having this project in a separate solution and referencing the compiled dll. Any changes you require you would need to open up the solution, make the change, build it, go to the solution you're working in and test it. Sounds like a pita and you find it's just simpler to have it all in one big solution. But then if you have this library in every solution and make a generic change to it you need to repeat that change through out.
So you just need to make a decision on wether you're developing a separate project in the same solution or something that might be used elsewhere. If you needed more functionality than the library provides you could implement a partial class in your project and extend the library in that way. Or perhaps a wrapper class will suffice. But then you know you're not affecting the other sites that use this library and you are keeping your solution smaller and more manageable with a smaller memory print during development.
I am the CTO and sole developer for my company. I'm getting ready to hire our first developer and possibly a second within the next 6-12 months. I'm embarrassed to say that I've never used source code control as part of my workflow. I guess being a 1-member development team has allowed me to be a bit lazy. It's not that I haven't wanted to, I just have a bit of a mental block about how to get started with it.
We have 5 web applications that I build and maintain. We use ASP.NET, and each web app references a single .NET Class Library (DLL) that has been copied into the "bin" folder for each app. I've been developing with a single Visual Studio "solution" that includes the class library and all of the web apps. A bit bloated, I'm sure, but this method has made it easy for me to minimize mistakes by enabling me to do global find and replace operations on all of my apps (and the class library) at the same time.
I realize that implementing source code control is a big change to my workflow by itself, but also introducing another developer into my process has me a bit overwhelmed. I'm looking for some assistance on how to develop a workflow that will enable my small team to move quickly without cumbersome processes. I'd like to avoid discussions about which SCC system to choose (we're going to use Mercurial). I'm more interested in discussing the structure and workflow aspects of this.
Here are the questions I need help with:
Should I split up each app into a separate "project" or keep them all together so we can continue to benefit from global find-and-replace operations when necessary. I'm worried about splitting them up because of the class library situation (see #2).
If splitting up the apps into separate projects, I'm not sure how to proceed with the class library that each project needs a copy of. For example, let's say that the changes to one of the apps (call it "project 1") requires a change to the class library... if the class library is in a separate project (call it "project 2"), it seems "messy" to me that project 1 would be dependent on the latest changes in project 2 in order to work properly. Or, do you simply make your changes to project 2 (the class library), check them in, and then copy the newly compiled dll into project 1 (but shouldn't the new copy of the dll being copied into project 1 be recorded in the SCC somehow). I'm getting confused even as I write this...
Thanks in advance for your help.
First, congratulations on deciding to finally use source control. I know changing your habits can be frustrating but in the long run I'm sure you'll see the benefits.
There's nothing wrong with a solution that has multiple projects in it. I generally keep mine to about 10 but that's simply to improve load times. If keeping them together works better for you, leave it that way. Usage of source control won't have any affect on this.
As far as the class library, I think what you need to do is change the way you go about making changes to the library project rather than how you use the projects that reference it. Implement unit testing on the library project to enforce backward compatibility so you know that dropping the latest version of the library won't break your app. You'll likely find this won't be true a few times but as you develop more unit tests to handle edge cases this will happen less and less.
You can have multiple projects in a single Visual Studio solution. What I've done in the past is to have both the ASP.NET project and the class library project in the same solution. You can have your ASP.NET project reference the class library project (Add Reference and then go to the Projects tab to show other projects in the same solution). That way, whenever you change the class library, the ASP.NET application will be build using the latest version of the class library. You can setup multiple solutions - one for each ASP.NET application with each solution including the class libary project.
You could also setup one large solution with all of your ASP.NET projects as well as your class library but that may get a bit hard to work with, especially with multiple developers working on the different ASP.NET pages.
I'm doing some work with several shared .NET assemblies and a generic web application that I would like to handle better in our CC.NET/NAnt build environment.
Currently, we have several .NET assemblies (shared common code that we use in client projects) that exist in different .NET solutions within different repositories in our SCM (Vault incidentally). They are all configured under CC.NET separately so we have a decent amount of control over their build and deployment at present.
We have developed a CMS system that uses some of the .NET assemblies and includes a common administration website project and a template website example project. Out of this one solution we have the following elements that need to managed separately:
Admin interface is not tied to .NET so it is template based and we are developing a PHP backend for it currently.
CMS shared assembly build on top of our other common company wide assemblies.
Control over functionality within each major CMS build/release.
I'd like the build output of this solution to be a Visual Studio template, which we can use to develop other client sites and better manage version changes within the CMS itself, as we add features to the codebase.
I have a rough approach for all this and think it is achievable, however, I wanted to open this topic up for discussion and see what everyone else is doing when it comes to managing the build and deployment of multiple solutions.
Main considerations for us are:
Do we make use of the integration queue functionality in CC.NET to ensure a build order and pull together the assemblies we need for the CMS at build time?
Debugging within a CMS client site i.e. stepping into the shared assemblies' code when the client solution is a version of the base CMS system and therefore separate.
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
Any other issues people might have experienced that could change our way of thinking?
Hopefully this question isn't too vague and some of you will have dealt with these issues. Look forward to hearing everyones experiences.
Many thanks!
Tim
I unfortunately cannot answer all of your points, but let me start with this one:
Do we make use of the integration queue functionality in CC.NET to
ensure a build order and pull together
the assemblies we need for the CMS at
build time?
The short answer is -yes, you should. The queue attribute ensures a build order within the running instance of CC.NET and is gives you serialization of the builds that depend on each other. For specifying which projects depend on each other, you should use project triggers. Do not rely on the queuePriority for this task.
You shold most likely pull the pieces you need to do the build at build time. Unless you have some time constraints on your individual builds.
Re:
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
I'm fundamentally against distributing binaries in the trunk unless it's some libraries that does not need to be updated/changed on a frequent basis. If you build the shared assemblies yourself, you should consider pulling them from the artifacts on the build server(s).