I've started working on an existing, large ASP.NET project and I'd love to get some feedback on better ways to organize the project as a whole. This question was somewhat related but doesn't really have enough specific details to help an ASP.NET newbie like me.
The site isn't terribly complicated. There a number of themes that can be applied to give the user different styles & functionality and most of the common elements between themes are placed in UserControls.
The problem is that, when the project is compiled, the whole thing gets built into a single, massive DLL. That means that making changes across a number of UserControls and then rolling out those changes a few at time is incredibly difficult, if not impossible.
Unfortunately, we have to assume Visual Studio 2003 and .NET 1.1.
Like I said, I'm an ASP.NET newbie so be gentle.
Is there a way to do things differently so that maybe each UserControl is its own separate DLL?
Are there other things I could change to make it easier to push out changes in small batches?
The way we do things at my current job is to compile multiple small DLL's. Controls typically have their own DLL separate from object logic so we can use objects in things like windows services. This does require recompilation of the entire project though.
We use cruisecontrol.net which has some neat features which builds the entire project in the background. You can set up projects so that when you chagne a DLL, cruise control will recompile every project that references the DLL. It's a very handy feature that takes the onus away from any one person as the build master. You just wait for cruise control to build the project and you receive a success/failure email when it is done. Not sure if this is what you're looking for. I'll be glad to go back and forth with you if you need any more help !
good luck !!
Related
I am writing a C# application with Visual Studio that is divided in several modules (namespaces). Every module of course is going to be in charge of some particular function. For example there is a module that will deal with calling some firmware some place else, another module that will deal with just the UI with the user etc.
So far I have no problem doing that. But while writing the first module, I realized that perhaps the classes that I create for this, could very well be used for other future projects since their architectures seem similar.
So I am wondering if it would be a good decision to:
write a separate DLL that deals with all this functionality from scratch and then call that in my project
or just write the project, make it work and then later separate the particular module and shape it like a DLL.
You have to look at all the options and consider everything.
If you create a separate library then you need to be sure that you know all the requirements ahead of time, so that you can keep the library as stable as possible. As, each time you update the library you will need to update all of your projects which use it.
Creating a library will be at least little more work initially.
A well designed and developed library will give you the ability to be able to just drop it into a future project and be sure that it will do what you want.
A badly designed one will mean that you keep going back to it to make changes time and time again and have to keep updating all your projects, or maintain backwards compatibility which means you could end up with multiple different versions of the same method. And end up with something difficult to maintain and update.
You have to weigh all of this up against the advantages you would gain by using a library.
My experience, is that if you need to do something twice then often copy and paste is better. If you need to do it more than that, or sometimes if it is quite complex, then a library starts to pay off. But still for little things copy and paste is still easier, quicker, and lighter.
Updated.
Updated the question since it looks little ambiguous and not the answer i was looking for.
We have a huge .NET application running on MVC and angular. It has multiple projects under the main solution. .
We also have a replica of that application in Node.js for front end developers.
It looks something like this :
What happens is - Front end developers make changes in Node js solution (like js or .less files or controller) - make changes and move those changes to .Net solution which is the actual live project.
Off late - we have issues with developers working with two different solutions (Node and .NET) and keeping two copies of assets everywhere.
We ultimately decided to combine them and bring the whole Node.js application into ours .NET Solution as 6th project.
Something like this
Wondering if anyone has previously done so - adding a .NET application with existing Node.js application. If so any pros and cons to consider.
Some points to note - the Nodejs project and .Net project are completely independant of each other. The idea is to consolidate the applications so that We can either run the .net application or UI application from single solution.
Eventually, we will consolidate all the assets to just one project so that - we dont have to do duplicates.
Also, would appreciate any links where I can see how to start merging these two applications.
You definitely want to look at JavaScript Servcies. Building Single Page Applications on ASP.NET Core with JavaScriptServices.
Made for .NET Core, but you can run .NET Core on Full .NET Framework, which should make it easier to migrate to.
What I think you have is, say, a production version in .NET and a development environment in node.js for developers which prefer that.
At the company I work for, we use AngularJS for our front end and .NET/Entity Framework back end and it works pretty well.
I'm not sure if you are integrating some sort of JavaScript back end in with it or not. Assuming you are going to stick with a .NET backend and a JavaScript heavy frontend, it should be fairly easy.
That being said, nothing in this career is truly "easy". I would recommend using an AngularJS frontend as it has seemingly endless functionality.
Some minor suggestions if you choose that route is to check out John Papa's style guide. great reference for writing AngularJS. Make sure you have consistent naming, especially in Visual Studio as AngularJS can be a little moody.
I prefer to bind values to the view when working on AngularJS, e.g.
vm.title = "Data I want to bind"; in the view: <h1>{{vm.title}}</h1>
If that renders as {{vm.title}} instead of Data I want to bind you know something isn't working. I prefer catching it sooner rather than later.
Dependency Injection is another thing to be careful with, the style guide covers it as well. Basically if you minify your AngularJS files and the minifier removes the information required for DI, your project will break. I've been down that rabbit hole a few times.
If you aren't intending on using AngularJS then forget I said anything. I was just exercising my fingers. I hope that helps shed a little light on your decision.
I hope this is not an obscure question. I expect there are several ways people accomplish it and the approach I'm using seems excessively labor-intensive.
How do I break apart a presentation-layer project (XAML/WPF) into several temporary "side-by-side" projects so that I can make enhancements efficiently in VS 2015 and unit-test them quickly? The end result being that, once the unit tests are successful, I combine the projects back as they were again (with a focus on organization rather than developer efficiency).
The problem for me is not one of analyzing the inter-dependencies, not one of identifying project boundaries, and not one of adding the newly created (temporary) project references where needed. The biggest problem I have is with all the silly XAML namespace references (clr-namespace:). They need updating so they will point to the new home assemblies (assembly=) for the referenced resources. This is a ton of overhead and doesn't always have a pay-off since it is temporary work in the first place. Where is the tool to do this for me? And revert it back out afterwards so that I don't accidentally promote temporary XAML changes into source control?
I thought about managing an entirely separate set of sln's and csproj's for WIP development but this is impossible for the same underlying reason based on the way those XAML namespace references (clr-namespace:) work. Also it is hard to do it as a team effort.
More info:
The reason I ask is because we have a number of projects with XAML resources (user controls, resource dictionaries, etc). Some of these get quite large because they are organized in a certain way that makes them a common place to put stuff (ie. all the combobox lookup - ALT-down - windows, or all common data templates, or what-not). Over time it becomes a problem because VS build operations take too long (impacts development efficiency). VS build operations get slower for larger projects:
a project with a centralized list of all data templates is likely to have a lot of things above it in the dependency stack, causing numerous other projects to be rebuilt after every change
any project with a central repository of anything will grow large and take a long time to compile (5 seconds /project is about my limit while I'm actively developing XAML, with a cap at 10 seconds to do the entire build operation and start debugging)
The biggest problem I have is with all the silly XAML namespace
references (clr-namespace:). They need updating so they will point to
the new home assemblies (assembly=)
Generally, ReSharper does great job, when refactorig xaml. It analyzes xaml files, and fixes wrong xml namespaces. However, you would need to go trough all the files, one by one.
You can also use just plain Find/Replace dialog and replace ;assemmly=TempProject with empty string. Write powershell script for that, if you need to do it more often.
And revert it back out afterwards so that I don't accidentally promote
temporary XAML changes into source control?
You just need to be carefull when doing check-ins, compare files with they original version and investigate changes
However, there is only one good solution for you. Split the projects into wpf usercontrol libraries. Not just for testing purposes, but permanently. Try to break your large resource files. Don't use practices like common place to put stuff when working on large projects. Consider using loosely coupled design and IoC (assembly injection instead of direct references) when possible. Create this shared assembly, which all other assemblies will reference. Don't create component that references lot of other components, but let the others inject themselves instead. Take a look at prism for an insipration: http://www.pluralsight.com/courses/prism-introduction
i have a project where i do something i have same copy from another who have do something in it later i have a thing to do currently.
so that's three copy and i am unsure that i am not confused with it. sometime i call wrong copy for finding the thing i want from them.
without using any software outside our office window any trick to manage all project or how i can manage them and make them one copy.
the same problem with some other problem come with when the same script used in two software , website who are used same script with have a small difference in both.
so i want to know how exactly all other manage them. i want to have a answer with .net plateform.
There are several source control solutions that have plugins to integrate directly with Visual Studio. I would recommend looking into Subversion. Currently at my office we use Vault, but it has some short comings, especially when it comes to renaming or moving a file and then editing it prior to a check in.
http://ankhsvn.open.collab.net/
http://www.sourcegear.com/vault/
I recently started a small pet project. It's written in C# with ASP.NET MVC3. As it's grown, my needs for source control also has grown. Here's what I've done:
Day one, I placed my project in a Dropbox folder. That way, I could reach my project files from all my computers (and even my iPhone).
A few weeks later, when I first had to make some serious changes and neede a fallback, I created a Mercurial repository in my Dropbox folder and commited all my code. I've got a blogpost on that here: http://csharptutorial.blogspot.com/2011/06/using-dropbox-with-mercurial.html. Mercurial is a great versioning system, because it doesn't require a server installation and your repository is copied in full to all locations where it's checked out.
Now, I'm looking at moving my project over to BitBucket (http://bitbucket.org/) where you also share and discuss code with others.
A good alternative to Mercurial is Git, using github.com in stead of bitbucket.org. Both have a learning curve, but they both represent modern version control tools and is well worth having a look at.
Source control and discipline.
You need to get an approach and method for managing your source. A source control system is essential for this. I use SVN and Ankh, as does Clayton.
However, you need an approach for using this. I always have branches. You can have development branches and merge these changes into a release branch when your code has passed all the tests. This way takes a discipline and time, but you need to do this to build quality into your system.
I googled this a little but couldn't find a good result.
Right now I'm building a web site and I'm trying to make it as correct as possible from a design point of view from the beginning.
The problem I'm now facing is that when deciding to start with logging I needed a project to place this code in. As I could not find a suitable place in my currect projects I thought: hey, why not a logging class library?
Is there a general guideline on how many projects you should have? I know this would be a rather small project but it would be nice to entirely get it out of my way!
Any hints are appreciated :)
Absolutely you should have a logging library. And if you're going to make this as 'correct as possible from a design point of view' and your proect is less than trivial then you should definitely have some number of projects. The thing is, we have no idea what you're working on besides the fact that it's a web app. It's the biz domain that often determines how complex your solution has to be.
I'd go for a three-tier architecture for a small project.
This would include:
Application Layer
Business Layer
Data Layer
but if you want to add logging, it would be best to create another project. This would also help you so that if you want to add logging to another application, you can just include the logging project.
Either way would work, if you are concerned about project limit in a solutions. Don't be.
I myself would put it in a separate project or a utility project.
We have a solution with 200+ projects. The downside is long load time in Visual Studio. But past that the only issue is making sure you have enough RAM.
Also, MSBuild.exe has built-in support for SLN files, so look into using that instead of Visual Studio if you are doing automated builds.
"That which changes together should be packaged together", I forget where that guideline comes from (Code Complete maybe?).
In other words your assemblies (projects) should represent a coherent abstraction in the same way your classes/objects do at a lower level.
So yes, a separate logging project is the right way to go (although do check out log4net or Microsoft's logging block before you roll your own!)
Put a logging into a separate project is perfectly fine.However it really depends on the scope of your project.I normally setup my project like this
YourProject.Web(web project)
YourProject.Core(all the business logic)
YourProject.Web.Tests(Watin tests)
YourProject.Web.Core.UnitTests(Unit tests)
YourProject.Web.Core.IntegrationTests(Integration tests)
I suggest you to download some open source Project from asp.net to see how the project have been organized.