I am pretty new to mvc but have already read a few books.
What I want to archive is:
-> Having the main asp.net app in its own project.
-> Every modul (for example forum modul) is hosted in a regular dll (including its controller, models and views).
I've looked into the issue of hosting controllers in different assemblies. This is actually easy to handle. But what I do have issues with are the views.
I could not find any resource regarding how to tell mvc that he should look for the views in this namespace the the other view in the other namespace.
Best regards
Simon
Have you imported the projects/assemblies in the project you need to use them?
Look in the References folder. They must be there so you can use them.
I am not quite clear why you would use this style of architecture, but again that's your choice.
What I can confirm is that it is not going to be as useful as you think.
A detailed explanation is here
I have an ASP.NET 4 web application that references a SOAP web service. I have an (old fashioned) Web Reference to this web service in my project. When I compile/build in the IDE I get no problems and Intellisense and the Class Viewer all show me that VS knows what is what and where to find it.
However, when I run the solution, I get this error:
The old CS0234 error (The type or namespace '<...>' does not exist...). Intellisense begs to differ.
My web app assembly is called NovaWeb and my Web Reference is called WS3. I can see that my Reference.cs file contains the following:
namespace NovaWeb.WS3 {
This was all working great a little while ago, but I apparently changed something and now everything is broken. I've tried cleaning out all of the files in the /bin folder and all of the temporary ASP.NET files in my appdata folder.
Does anyone have any suggestions about how I can troubleshoot this problem?
EDIT: My Work-Around...
I've still got the troublesome project laying around in case someone suggests an answer. I can give it a try to see whether a resolution exists. In the meantime, I couldn't wait for a real resolution so I've taken a work-around.
What I've done is started from scratch with brand-new VS2010/.NET 4 web application projects and moved my source code files over into the new projects piece by piece. There are a few salient differences between the busted-down solution (.sln) and the work-around solution. These are:
The work-around has one solution (.sln) per project. The problem solution had two web applications and three EF4 data library projects in a single .sln.
The work-around solution was started from a green field (empty ASP.NET Web Application) template within VS2010 and targeting .NET 4.0 from the outset. The problem solution had parts that began life in VS2008 and originally targeted .NET 2.0.
The work-around project completely avoids any hint of an App_Code folder. The problem solution had a project with an App_Code folder containing a few utility classes. I'm not sure that this makes the slightest difference, but I did run across at least one posting that suggested the compiler might be confused by a code folder called App_Code in a web application project.
"I gave up and started over" is not much of a resolution to a problem, but I thought I would leave it here, along with this question - in case someone happens by with a solution or in case it is at all helpful to the next person with the same problem.
I'm not usually one for answering my own questions. However, this question has been open with no answers for over a month. It's had a decent number of views, which makes me wonder if others might not have the same problem. Since I've finally found the solution, with the help of some direct support from Microsoft, I thought I would document my solution in case it helps the next person to stumble on this error.
So it turns out that web services is a red herring with this problem. The real crux of the issue is the runtime CS0234 error relating to a referenced type. It can also manifest itself as a runtime CS0103 error too, as I found out the hard way.
I mentioned in my question that I found a work-around. The work-around eventually stopped working and I was out of the water on this project. I contacted Microsoft for support and after four days with my source code they came back to me with a solution.
The problem was related to my compiler configuration for target platform.
Due to some agony that I've suffered in the past over deploying multi-assembly applications on the desktop, I have gotten into the habit of changing my build configurations from Any Platform to x86.
This can apparently mess up your compile for an ASP.NET web application. That smells badly like a Visual Studio bug to me, but nevertheless, the solution to my runtime error was to go to the Solution Properties (not project properties) and to select Any Platform for the build target.
I hope this saves someone some aggravation. If anybody has a reasonable explanation as to why this is not a VS bug or what is going on under the covers, I would be interested to hear it and I promise to upvote you for your trouble!
Disclaimer:
This is the first time I am asking a question that might be classified as subjective. As English is not my first language, it is hard to phrase this right. So please feel free to edit the question in order to make it clearer, or to point me at other ways for asking this.
Intro:
David Ebbo (architect on the ASP.NET team) just posted on Register your HTTP modules at runtime without config using the seemingly undocumented PreApplicationStartMethod assembly level attribute
I have mixed feelings about it.
On the one hand it is good to be able to do things as early in the application startup phase as possible.
On the other hand: Does it suffice? Do we need a PrePreApplicationStartMethod allowing to fiddle with the PreApplicationStartMethod behaviour? What about expansion to non-assembly use (for instance, NuGet already works around the single-use-per-assembly restriction of PreApplicationStartMethod)?
Question: Besides using it for config-less startup, what do you think of the PreApplicationStartMethod attribute?
I think one of the good usages for this is that it allows someone who is writing a 3rd party assembly, or a team that is working on an assembly that will be used in many projects, to be able to use this attribute to initialize stuff w/o requiring the end user/developer to create anything in the global.asax in the application startup events.
There are lots of app specific stuff that people like to/need to configure in global.asax, but if you are creating a DLL, you no longer have to make the user configure your classes in the global.asax, you can just put all your logic in your own init/bootstrap function and rely on asp.net to call your init logic when the app starts.
I want to Implement Logging future using log4net for my asp.net mvc application..
Can any body has the Sample project so that I can take a look? and where do i need to find out the dll's for log4net?
Thanks
I Used this link to implement Loging for my application
http://www.codeproject.com/KB/aspnet/log4net.aspx
How do I need to log this error to my database table? what do I need to write in my Class? to store the values in the table
thanks
Get it from here.
Here are some examples.
Well to be honest you hardly made an effort if you couldn't find the DLLs, which are available here.
You will want to add the DLL as a reference in your project and then follow the directions here.
This guide might help you:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
You can download the source code and the DLLs from here:
http://logging.apache.org/log4net/download.html
I have looked through the related questions, and none of them have provided me the information I am looking for.
Currently the team I work on does deployments of individual .aspx (and .aspx.vb) files for bug fixes/enhancments. I am trying to affect change, as I really believe that deploying the "whole compiled site" is less error prone. As this is a significant change from the way things have been done, my suggestions have ben met with significant resistance.
As my google-fu has not been up to par lately, I was hoping the SO community could either tell me that I am off my rocker, and that there is nothing wrong with moving individual files, or point me to some really good resources which would allow me to make a stronger case.
Edit:
This has all been great info, and reinforces the arguments that I have already been making, can anyone argue the other side?
Deploying individual files for bug fixes and deployment is not a wise strategy. It sounds like you need a comprehensive build and deployment process. That doesn't mean it has to be complicated as there are some good tools available nowadays.
Build and deployment can get detailed, so as a minimum start try taking a look at the Microsoft Web Deployment Tool (http://www.iis.net/extensions/WebDeploymentTool). Install the tool on your build server and install it on your deployment server. Stage your ASP.NET content locally using the Visual Studio Publish command, then use the above tool to synchronize the entire package on the deployment server. I like this approach because it can be completely automated. When doing builds and deployments, aim for complete automation to reduce potential errors.
This is the bare minimum, but you will at least be certain that when specific files are changed, they are ALL synchronized on the deployment server.
Personally to me rolling back immediately is most important. Again website projects are very hard when it comes to track the changes.
you can find a good detailed comparison here. I am reproducing the article here.
1) Deployment. If you need in-place deployment, this model is perfect. However, it's not recommended since you are exposing your logic in clear text. So, anybody who have access to physical server can mess with your code and you never going to notice this. You can try to make precompiled web site, but you going to end up with a lot of dll and almost untouchable aspx files. Microsoft recognized this limitation and released Web Deployment Project tool.
2) You need to keep track of what did you change locally and what did you upload to production server. There are no versioning control. Visual Studio has Web Copy tool, but this tool fails to help. I had to build my own tool, which kept track of changes based on Visual Source Safe.
3) When you hit F5 for debug execution it takes merely 2 minutes to compile and execute whole project. Of course you can attach debugger to existing thread, but this is not an obvious solution.
4) If you ever try to generate controls on a fly you will hit first unsolvable limitation. How to reference other pages and controls. Page and control compilation happens on a per directory basis. On best case you going to get assembly for each directory, in worst each page or control is going to get its own assembly. If you need to reference another page from a control or another page you need to explicitly import it with the #Reference directive.
So for,
customControl = this.LoadControl("~/Controls/CustomUserControl.ascx") as CustomUserControl;
You need,
But what if you want to add something really dynamically and can't put all appropriate #Reference directives? Or What if you are creating server control and it doesn't have ascx file, so you don't have a place for #Reference ? Since each control has it's own assembly, it's almost impossible to do reflection.
Web Application Projects which re-appeared in Visual Studio 2005 SP1. They solves all issues mentioned above.
1) Deployment. You get just one dll per project. You can created redistributable packages and repeatable builds.You can have versioning and build scripts.
2) If you did code behind change you can upload just one dll. If you did aspx change you can upload just aspx change.
3) Execution takes 2-3 sec maximum.
4) Whole project is in one assembly, which helps reference any page or control. Conclusion. For any kind of serious work you should use Web Application Projects. Special thanks to Rick Strahl for his amazing article Compilation and Deployment in ASP.NET 2.0.
I agree with Rich.
Further information:
Deploying your SOURCE code ala the .vb files to the server is a BAD idea. Compile it. Obfuscate if you can, just don't deploy straight source. Imagine an attacker which gains access to the system. They could easily change your code and you might not ever notice. Yes, you can use a tool like reflector to decompile. But it's really hard to decompile a full site, make the changes you want, and put them back into production.
Deploying a single file might very well cause some type of problem in a related module. I'm guessing you guys don't really do QA. Tell them it's time to grow up.
Compiling your site will reduce JIT (just in time) compilation. Think performance.
I'm also going to guess that pretty much everyone has production server access. This is bad from the company's perspective as you have no controls in place. What happens when an employee decides to cause some havoc before leaving?
What you are describing is inline with Cowboy coding. Sure, it's fun to ride to the rescue but this style frequently blows everything up.
It's bad for rolling back. If you deploy as a web site vs web app, yeah you can do quick patches of one or two files, but what if you ever need to roll back to a previous version? Good luck tracking down all the files that were updated to make the new version. I much prefer the concept of a "version" for organizational reasons, and the compiled web app is much more inline with this than a "website" project.
We had this dilemma and ended up going with the compiled version mainly for the security reasons. If your site is external facing you could be compromising your security by allowing the vb files to be out there in plain text. I realize one could still get your code if they really wanted to but it would be an additional hurdle they would need to go through. If you use Visual Studio as your development environment you can publish the site pre-compiled and check the named assemblies option when publishing and this will essentially create a dll for each aspx page so you can do the one off page changes if necessary. This was a great feature we found as we were constantly updating the whole site and there were times when things would get updated that shouldn't. After using that feature we no longer had updates getting pushed that shouldn't. As far as rolling back I hope your using some type of Source control / versioning system. Team Foundation Server is great for versioning/source control but it is quite pricey.
What is the best deployment strategy depends a lot on what kind of environment you are working in, and what kind of developers you are working with.
Visual artists that started with graphic layout and worked towards programming are much more in tune to individual page generation and release. Also the .aspx.vb files are simply server side scripting, not really programming.
Programmers usually start at the command line and branch out to environments such as the web and understandably feel that good programming practices should be applied too the web, including standard test and release cycles (and compiled code).
If the site is in constant flux the individual pages would make more sense, but if you are required to deliver an installation package to your production group msi files are the way to go, since they can be easily backed out if necessary.
If you evaluate what your groups needs are, which includes the varied experience of everyone in your group, you should be able to convince either yourself or the group. This is not a matter of which is better, but which provides the best business model.