this is likely a naive question, but I want to do this right the first time.
I have a MVC solution which has the following:
Data project - C#
Services project - C#
MVC Web Project - ASP.NET MVC
Test Project
Currently, I am using the MVC2 source as a means to debug my own code. I do not plan on checking that in, but I realize once I go back to the MVC2 DLL, my solution will change.
I'm pretty sure I just shouldn't check in stuff that changes with each build: the bin folder on the Web project, for example.
Is there a list of what not to commit to source control? :)
Exclude the bin folder. Also be on the look out for .user or .suo files. Those file store your own settings and will change from user to user so it shouldn't be in source control.
If you're using a database stored in the App_Data folder, be sure to ignore that as well (the database file, not the App_Data folder).
Generally, I exclude the bin and obj folders of every project from source control. I can't remember needing to do anything else.
do you use ankhsvn?
i think ankhsvn automatically exclueds directories which are not needed in subversion
cheers
Related
If i release(publish) a mvc project to a folder. Lets say I make a change to _layout later in my solution and publish again, what files do i need to update on the ftp? bin or (_layout in views folder)?
When do I need to update stuff in View or bin?
bin folder contains your dlls, you project dll let's say project.dll is subject to update when you compile your server side code.
Otherwise it is enough update only relevant view file.
You can publish one invidual file thus update it to ftp
One query regarding a Web-Site project in Visual Studio -
I did following steps -
Created a WebSite using VS 2010
Added a custom class in App_Code folder and consumed it in default.aspx
Run the application and I can see the result
Any changes made in server code are reflected on the browser without doing any recompile (website feature)
So, when dynamic recompilation takes place for a web-site, somewhere .net run-time will be storing the compiled dll, isn't it?
Can anyone please guide where I can find the dll being generated during dynamic build are stored? (I just want to know this out of curiosity :-))
Thank you!
P.S. I also did a 'Publish Website' and I can see a bunch of compiled dlls in the publish folder. So, my Question is only regarding dynamic build.
The dynamic created files for your web site are stored on
c:\WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files\
You can change this directory on the web.config. The asp.net check if any file change on your site and if can find any changes is start the recompile. Also many parameters of the recompile can change on web.config.
How to change this directory
<compilation tempDirectory="" ...>
and this is the rest of the compile options: http://msdn.microsoft.com/en-us/library/s10awwz0(VS.100).aspx
You may find the name & location of Code Gen Directory via property of HttpRuntime.CodegenDir programatically.
I'm a real newbie for ASP.NET web development, having a background in Java. A friend has an ASP.NET 3.0 deployment running on IIS. He can't find the original project files created in Visual Studio 2008 and has asked me to give him a hand.
Is it possible to recreate the project from the deployment on IIS? I see lots of ASPX and and CS files so in the inetpub[domain]\httpdocs directory.
I don't see the .SLN file. I assume that's what he needs. Would it be a real chore to rebuild? Are there any assets or source files that won't be deployed to ISS that I'd need to recreate?
Thanks
Re-creating the soloution/project files is (potentially) a small part of the recovery. Do you see any .aspx.cs or .aspx.vb files on the web server? If not, you'll need to extract the code from the code for each .aspx file from the DDL's in the web site's /bin folder. You can reverse engineer any .Net code quite easyily luckily with reflector, however all comments will be lost.
If you have the aspx and the cs files, you are in business: all you need to do is create a new Web Project in Visual Studio and select "Add Existing Files". You would then select all your aspx pages only and the cs files should get automatically imported for you.
Obviously, as anything, you'd probably have some references missing and what not, but shouldn't be incredibly painful to fix all those issues.
If it's a compiled web application project the code will be in a compiled assembly in the bin folder. This can be decompiled with .NET reflector. The source will be readable but not as original.
If it's a website project you're in luck. The code files will be in the website structure (*.aspx.cs or *.aspx.vb). These will constitute pretty much all of the assets you need to recreate the site in Visual Studio. Creating a project and solution file to manage these in VS will be the easy bit.
I'm using a Web Deployment Project in Visual Studio 2008 in order to prepare my ASP.NET application (ASP.NET web application, not ASP.NET web site) for being copied to several servers. I have to copy the files on local staging servers, on different servers via FTP and sometimes I have to fetch them from customers' servers.
So, it would be nice to have all files for deployment in a compact form without the necessity of doing a lot of comparing between source and destination. Web deployment projects have this nice feature: compile all your aspx and ascx files into a single (additional) assembly.
I somehow found out how to get rid of aspx placeholder files on the server, now I'd like to know if there is a (maybe self-made) way to get rid of these .compiled files.
From Rick Strahl's blog:
The .Compiled file is a marker file
for each page and control in the Web
site and identifies the class used
inside of the assembly. These files
are not optional as they map the ASPX
pages to the appropriate precompiled
classes in the precompiled assemblies.
If you remove the .Compiled file, the
page that it maps will not be able to
execute and you get a nasty execution
error.
Anybody out there with a creative idea, maybe using a module/handler which intercepts the check against the .compiled files in the bin folder?
The .compile file comes from pre-compiling on deployment. So you basically have 3 options:
Keep the .compiled file
Don't pre-compile and deploy source code
Turn this in to a Web Application instead of a Web Site and compile as an assembly
I have run in to the same problem myself. I actually choose #1 in most cases when dealing with deployment of Web Sites, but on the rare occasion when I know I am going to have to maintain the site for an extended period of time, I take the time to upgrade it to a Web Application.
I don't like the .compiled files either, but nobody gets hurt if they're there. So why bother?
You might want to take a look at Virtual Path Providers (KB how to here) in ASP.NET.
Credit for this suggestion must go to Cheeso and his self answered question here:
Can I get “WAR file” type deployment with ASP.NET?
I don't know about the .compiled files, but you could set up your servers to update their files with subversion instead of manually copying the files when you compile.
So you would compile the files using the Web deployment project (not into a single assembly), put them in a repository you created for this purpose, and on each server, just do an svn update to fetch and compare the files automatically.
I know it's not what you asked for directly, but it may be a path to explore.
Add "Exclude Filter" to your deployment project:
In the Deployment Project.
Right Click on Content Files.
Click on "Exclude Filter".
Add "*.Compiled"
click OK.
and thats it.
I remember at the days when I cant do Web Application with VWD Express, I use nant script to compile the project into a single dll and deploy, that would work (so I dont need the full VS to do dll deployment too), so if you really don't want to mess your project to Web Application, maybe this is a path to check too.
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
If you publish your code as updateable (in publish settings) these files are generated. Uncheck that value and republish. This is an old question I know, but no answers are clearly defined for this here.
I've discovered this folder in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files and have a few questions.
What does ASP.NET use this folder for, and what sort of files are stored here?
How does a file get stored here, and when is it updated?
Does the folder need any sort of maintenance?
These are what's known as Shadow Copy Folders.
Simplistically....and I really mean it:
When ASP.NET runs your app for the
first time, it copies any assemblies
found in the /bin folder, copies any
source code files (found for example
in the App_Code folder) and parses
your aspx, ascx files to c# source
files. ASP.NET then builds/compiles
all this code into a runnable
application.
One advantage of doing this is that it prevents the possibility of .NET assembly DLL's #(in the /bin folder) becoming locked by the ASP.NET worker process and thus not updatable.
ASP.NET watches for file changes in your website and will if necessary begin the whole process all over again.
Theoretically the folder shouldn't need any maintenance, but from time to time, and only very rarely you may need to delete contents. That said, I work for a hosting company, we run up to 1200 sites per shared server and I haven't had to touch this folder on any of the 250 or so machines for years.
This is outlined in the MSDN article Understanding ASP.NET Dynamic Compilation
The CLR uses it when it is compiling at runtime. Here is a link to MSDN that explains further.
Thats where asp.net puts dynamically compiled assemblies.