I have a project I was brought onto a few years ago and the original developer is no longer available. We have an Umbraco 6 based website. The solution has two projects, a Web Site and a class library call Umbraco.Extensions. I believe I read some conventional wisdom pertaining to Umbraco at some point where it is recommended to split it up like this but I am looking for more information about this particular style of setup and how it is supposed to work. For example right now I am dealing with a missing assembly issue, and i fixed it by copying a dll from the bin of Extensions to the bin of the Web Site. How is this handled regularly?
it's generally a good idea to keep the projects separated. You should have some kind of automation (maybe a post-build action) to copy the dll of the class library to the bin of the umbraco project. Or maybe rebuild the umbraco project with the correct references, but I dont usually do that.
Related
Using Kentico for the first time and have inherited a version 7 project with custom web parts. There are folders with .cs files, folders with .dlls, and folders with .ascx/ascx.cs web parts. Most are active. Some are not.
What's the best way to assess what is used and what is compiled when looking at a Kentico instance? I'm trying to sort what Kentico stores for configuration, how Kentico knows what to compile, and how Kentico provides a pathway for custom ascx/ascx.cs webparts to use (via using) various libraries in folders on the Kentico instance folder structure.
Having worked with Kentico for quite a while it's pretty easy to identify them simply by looking in a few directories.
If you haven't worked with it before you might try to do a fresh install of version 7 which you can get from the Kentico Client Portal and compare them.
If the install was done with best practices, you can look in the following documentation and the "custom code" should be in the green and blue directories in the documentation.
There is an open-sourced utility called KInspector (it`s made by Kentico consulting team). This utility should show you your custom code (among the others) in Kentico instance (afaik it is in the Analysis module).
I deployed my site on IIS 7. Can I edit c# files after deploying? In my sites's directory I see only .cstml files (Views), but there are no c# files... How can I do some changes in code without full redeploying? Thank!
Your project is likely a Web Application project. In that project type, the code files are compiled into an assembly (.dll) and that assembly is deployed to the server (the code files are not).
There is another project type called a Web Site, and that one works more like what you are looking for. The code files are deployed with the application, and if you edit any of them, the changes are available immediately (i.e. the code is recompiled).
There are other differences between the two, so please read up on them and decide if it's the right path for you.
Personally, I haven't worked with the Web Site project type in years. Back when it was first released, there was a big outcry against it (so much so that MSFT released an update to restore the Web Application project type), but this is all opinionated and it may work great for you.
There's an MDSN article that details the differences.
The intro paragraph tells you how to create a project of each type in Visual Studio.
At work we have about 30 legacy sites which run from a common set of code, currently these sites are in cold fusion. For this common code we have one project, then in IIS we set up a virtual directory to include the common code into each site. This works great, as changes to core logic can be made in one place, and its replicated through all the sites. And as all of our sites are hosted on the same servers, we can also just deploy the common code and all the live sites are updated, we don't need to release every site.
However we are in the process of re-writing our sites and core code into c# and asp.net MVC 3. Its going well, except when we update the core code, we are currently copying the dlls into each site, recompiling, then releasing each site.
This is fine while we only have a couple of sites re-built with the core code, but is going to be very painful when all 30 of our sites have been re-built in .net.
Does anyone have any ideas of how to easily use and delpoy common code without having to copy the dlls to every site?
So far we've tried:
- using a virtual directory of the dlls (doesn't work as site code needs to be re-compiled, and IIS doesn't seem to like it on .net sites anyway)
- deploying our common dlls to the GAC - this is an issue as the third party libraries (eg nHibernate) aren't signed, so can't add them to the GAC too.
Thanks
Saan
The easiest way is to automate your update procedure.
But if you want to rid of copying at all then you can try thing named "codebase".
Here is description of "How the Runtime Locates Assemblies" and details of "Locating the Assembly through Codebases or Probing" http://msdn.microsoft.com/en-us/library/15hyw9x3(v=vs.71).aspx
Interesting.
I also saw in the next .net relase they have http://www.asp.net/vnext/whats-new#_Toc_perf_3 “Sharing Common Assemblies”
This will give us a couple of options to investigate thanks.
Im currently developing an application with two web projects (MVC):
Frontend
Backend
These two are going to have almost the same layout (few minor changes). Therefore I thought about creating a MasterPage, they can share. But since it's two projects in two different locations, where should I put the masterpage, images and javascript?
The images and javascript (static stuff), could be placed on a CDN.
But how 'bout the ASP.NET specific stuff? Any suggestions? Any help appreciated!
A MasterPage is a UserControl under the hood, so any method of sharing UserControls would work for MasterPages. Unfortunately this isn't that great of an experience in ASP.NET as the BuildManager (what compiles and connects the app paths to classes during build-time) only recognizes & processes files within the current project.
Sharing code-behind, or base classes is easy and works well. It is the design surface (.master, .ascx, .aspx) that doesn't have a lot of ability to be shared. You can use a deployment project to compile a web app project into an Assembly that can be referenced, but you will still need some design files in your actual project.
This might also be of help:
ScottGu: Creating and Using User Control Libraries
SO: How do I share user controls between web applications in ASP.NET?
It's possible to include an existing file from another project in a new project. You can do that. So just put it in one project and include it in the other.
Alternatively, you can create a 'core' library, and put things in there, but that doesn't 'play' well with controls and so on, so I'd recommend the first approach.
I zipped an ASP.NET MVC Azure project up and copied it to another computer (both have VS 2008). I thought I could just unzip it in "Documents\Visual Studio\Projects", but I can't quite get it working. My site builds, but the browser doesn't see the master page or Site.css. Should moving projects around as Zip files just work?
My real question is, what's the best way for one developer to share an ASP.NET MVC Azure project among 3 different computers? Should I use something like Dropbox or Live Mesh? Or, github maybe?
OP here. The problem was that "Static Content" was not enabled in IIS on the second computer. The latest installation instructions for Azure (March '09 CTP) omit this crucial step. The first computer originally ran the Jan '09 CTP, whose instructions included the step about enabling Static Content. Moving projects around by zipping them up seems to work fine.
I love using git and github. I've shared my code among many computers with it. This was C# with Visual Studio solution files, so it sounds very similar to your situation.
Of course, I love git for source code management. I'd recommend it to anyone, but there's a decent learning curve if you're new to it. I can recommend resources that helped me, since it was really only about 8 months ago that I delved into it for the first time.
If you're not looking to adopt git as your source code management tool, then you might want to look at other options for moving code between machines.
Perhaps your IIS virtual folders are configured differently on the machines? You said it builds, but does not run. This suggests that configuration of the web site itself might differ between the 2 machines (and we're getting into some things I'm not aware of about how ASP MVC works at this point).
Yes, moving projects around in a zip should work assuming all of your files are in the subdirectory you zipped up. Sometimes you might add files to your solution that aren't in the subdirectory, and that can cause problems. References to other files need to be relative, instead of absolute.
A problem you might encounter is if both of you edit the same file, or accidentally overwrite an edited file with one from a developers machine that doesn't have that change yet.
Most developers use a source control system to share projects. Git is a fairly new one that has a growing audience. Subversion has been around a little longer and is very popular. Visual Studio integrates with TeamFoundation Server.
ProjectLocker.com offers free subversion hosting(so that you don't have to setup your own subversion repository).
Codeplex.com offers Team Foundation Server hosting for open source projects.
It sounds like the type of thing you see if the app-root isn't an application, or if the application isn't handling virtual directories correctly.
With virtuals; for example, you should rarely use "/foo/bar" - because if your app isn't installed at the site root you'll get unexpected behaviour - you mean "~/foo/bar", but this often needs extra code, as discussed here.