Have a question on "Temporary ASP.NET Files" folder; I have bit knowledge on what this folder is for as outlined by another thread in this forum
What is the "Temporary ASP.NET Files" folder for?
But recently, I am getting a warning while trying to build my new project as below
'c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\some folder\filename.cs' conflicts with the imported type ... using the one ...
Looks like that, two copy (shadow copy) of the same class (.cs file) file exist in two different version of temp folder and hence it's confusing as to use which one.
My Question is: Shall I go ahead and delete all contents from "Temporary ASP.NET Files" folder? Is there any side affect if I do so? Please let me know.
Thanks,
Rahul
If you close all of your instances of VS 2005, you can delete all of the files/folders within this folder. This folder is exactly as it's named -- Temporary. It loads all of the instances of your compiled files as they enter memory when they're loaded for a website. When you perform a "clean" on your solution it is supposed to empty the files in the folder relating to your open solution.
If you empty out your files and you continue to have this problem, then the problem will be related to how you have referenced projects and third party libraries within your solution.
If you take now your project, put it in a zip and send it to a friend, than he doesnt have the temporary folder for that project, and can build it too... So your main stuff should be in the project directory itself. Have you everything saved properly? Than close your Vs and clean the mess. (99% sure)
Have you tried to Clean your solution/project and recompile? That would only remove the compiled/temporary files associated with that project.
Related
i have 4 project in my solution, framework , domain objects,business objects and website ...
but this morning website project couldnt be loaded... when i tried firsttime to open solution... "The solution file has been modified outside the enviroment" message seemed and press reload then error is project file is corrupted... how can it happen... how can i fix this...
thx..
One way... if its from some source control , get the latest and leave the changed part by you.
If you dont have any source control then you can have the two options
- Create a new solution and add all your projects to it and rebuild it. Check for the errors.
- If your code is completely corrupted and files are unreadable, that is unrecoverable,
then you must have to follow this
copy the projects dlls out of bin
dir,
use red gate reflector and extract
all the class file in new project
file.
Now for aspx.cs you can create a new
project add all aspx file in that new project and also the
new cs files generated by the reflector addin. Do it for all pages. When done , right click on Project of web app(if its), then choose convert to web application. Also check the Page header of each page that they are using the same class files.
I know this is little bit tough , but will work....to recover almost that much code, when your app was last compiled.
Note : Also you will have to maintain the hierarchy of the project as the reflector add in (FileGenerator on Codeplex) might miss the actual project hierarchy.
You can open your solution file (.sln) in notepad and check for the consistency of the document.
The sln file will be in a hierarchical structure (like we have an xml).
You can also open csproj files of different projects that you have in the solution check the xml of the csproj.
Using a Visual Studio 2010 ASP.net web application, I have several projects that share some JavaScript/css files. The most logical way for them to share these files is to place the files in a single folder and each project has them included with the "Add as Link" option. However, if I add the files this way when I'm debugging using either the Visual Studio Development server or debugging using a local IIS web server all requests for these files return 404 Not Found errors. If I publish the site then the files are copied but that obviously doesn't help with debugging.
Is there something I'm missing or is this a failing on VS's part?
To overcome this problem some time ago I created a 'MSBuild.WebApplication.CopyContentLinkedFiles' nuget package. This package adds MsBuild target which copies all content files added as link to project folder during build.
Note: if you use source control then it is better to add copied files (from Web Application folder) to ignore list.
I wouldn't really call that a failing, since you asked for that behavior in the first place: linked items in Visual Studio projects are actual links to external files. Those files can reside anywhere on the disk and are not copied into the project folder.
You might want to copy those files locally yourself during a pre-build event. That way, the files will remain synchronized and you won't duplicate them until your first compile.
The problem seems to be that the website runs right from your source folders, rather than from the bin folder. This means that the file will be missing, whether or not it is copied to the output folder.
It's probable that running from a local or remote web server would not have this problem, though I didn't get that working, and I'd rather not add IIS to my local machine if I don't have to.
Adding a pre-build copy command did work. Note that the current directory will be the bin folder. (You can use cd to echo the current directory to the build window if you want to see it):
If the file is in another solution, your command will look something like (three ..s: one to get out of each of bin, project, and solution folders):
copy ..\..\..\OtherSolution\OtherProject\Scripts\MyJSFile.js ..\Scripts\
If it's in the same solution, but a different project:
copy ..\..\OtherProject\Scripts\MyJSFile.js ..\Scripts
One minor issue is that the link to the file will collide with the new copy of the file, even if you don't add it to your project. As long as you make the link first, it seems to work. If you copied the file first, you'll have to manually delete the copy, and then refresh the solution explorer before before being able to add the link.
Select the link in Solution Explorer and then look at properties window and set Copy To Output Directory to Copy Always. Linked items are set to Do Not Copy by default.
BTW, you can copy many files as links very easily directly from Solution Explorer when using VSCommands 2010 extension.
See this blog post about a simple addition to your project file.
http://mattperdeck.com/post/Copying-linked-content-files-at-each-build-using-MSBuild.aspx
We're a small team starting to use TortiseSVN to manage our web projects.
I was just wondering what is the best way to manage web projects into Subversion.
As you know a web solution consists of the .sln file as well as all the .aspx files.
Well we noticed when we right click the solution and we select "Add selected projects to subversion". It prompts me to tell it where to store the .sln file. So I give it some path like svn://serverName/CIS/MyWebSiteProject. Cool it just placed the .sln file...so I thought to myself how is it going to store the .aspx files as well.
Within a second I got a second prompt, I thought cool it is prompting me for the .aspx pages. So I tried giving it the path svn://serverName/CIS/MyWebSiteProject/ASPX_Files, but it comes back with an error stating I cannot place this folder within this path. I actually have to go outside of the folder MyWebSiteProject.
Not good cause now I have 2 folders one with the .sln folder and the other with all the .aspx pages and these folders are sitting on:
(sln file):
svn://serverName/CIS/MyWebSiteProject
(aspx files):
svn://serverName/cis/myWebSitePages
This really is not ideal cause I am sitting on the root of CIS with 2 folders for really one solution. Now when I try to check the project out I have to check both folders out.
What makes this even worse is when I do check them out I try to open the .sln file and I get an error that it cannot find the corresponding .aspx files. This seems like too much work, is there an easier way or a recommended way of using tortisesvn/subversion with asp.net web projects ?
While I am sure you have TortoiseSVN installed, it sounds like you are using Ahnk or some other VS SCC plugin to add from within VS.
I would suggest not using the plugin to initally add the solution to SVN, but to use TortoiseSVN in Windows Explorer for your initial check in. This will add your solution directory in its original state.
From that point on, you should be able to use the SCC plugin from within VS without trouble.
EDIT
Ok, after your commment I realize that I was not fully understanding the problem.
If you are dealing with a single project, after you create your solution and project, select the solution in Solution Explorer, go to 'file>save solution as' and save the solution inside the directory where your project file is.
Close the solution and go out to Explorer and use Tortoise to add the directory to SVN. If you have multiple projects/sites, just pick one to hold the solution.
Does that make sense? and from that point you should have no problems with ahnk
The key to successfully using Visual Studio with any source control is to put the solution file in the same path as the rest of the project files.
Usually, I will do something like the following:
\Project\Project.sln
\Project\MainWebSite\*.* <-- All web site files (including .??proj here).
\Project\Library\*.*
Then, I manually put \Project\*.* into source control.
Other options exist, as for my recent projects, I have been using:
\Project\SolutionFiles\Project.sln
\Project\MainWebSite\*.*
\Project\Library\*.*
Again, I manually put \Project\*.* into source control.
I generally find that it is better to set up the repositories for my solutions and projects from within Tortoise SVN. Then use whatever VS plugin that you care for to manage the commits of your pages etc. This gives you a little more control and allows you to get your setup correct from the start.
I have a Sitecore/ASP.NET projects that I'm developing. Today at some point I inadvertently hit the "Clean" option in the solution context menu. It took me a while to figure out why my site was hopelessly broken. Turns out Visual Studio went ahead and deleted several required assemblies from the \bin dir which are not part of my project.
How can I prevent this from happening again?
The odd thing is that it did NOT delete everything... just a small handful. It left many that are not directly referenced by my project. This makes me wonder exactly what this feature is supposed to do? Is there some sort of file flag I can set? None of the files are set to read-only. If you're interested in details, the following got deleted:
Sitecore.Analytics.dll
Sitecore.Client.XML
Stimulsoft.Base.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Web.dll
Stimulsoft.Report.WebDesign.dll
Telerik.Web.UI.dll
UPDATE: You know what... I guess what I'm really more interested in here is WHY Visual Studio is leaving most of the files and only deleting these specific ones.
The correct answer to your problem will depend on how you are referencing the assemblies and how you include them in your project output.
The bin and obj folders generated by a project are best considered "output" folders; these folders should only contain files produced by the project build.
When you perform a clean or rebuild of a project, all intermediary and compiled files are deleted from these folders.
You should be comfortable this is happening.
You should be able to restore these folders by running the build process at any time. If you have added files to these folders directly, it breaks the purpose of these folders and means you ought to rethink how you're adding those files.
The preferred way to reference compiled assemblies is to add them somewhere inside your source folders. From there, they can be added to a source control system as easily as any other file and can be referenced/copied by projects which depend on them. In my work, we have a "Libraries" folder which contains numerous third-party assemblies referenced by multiple projects in our solution hierarchy.
Try using a source tree like this and seeing if it works for you:
/Projects/My Solution/
/Projects/My Solution/Libraries/
/Projects/My Solution/Project A/
/Projects/My Solution/Project B/
We always add an AfterBuild event to the project file containing Sitecore.
<Target Name="AfterBuild">
<CreateItem Include="$(SolutionDir)\Third Party\Sitecore\*.*">
<Output TaskParameter="Include" ItemName="FilesToArchive" />
</CreateItem>
<Copy SourceFiles="#(FilesToArchive)" DestinationFolder="$(TargetDir)\%(FilesToArchive.RecursiveDir)" />
</Target>
Where the CreateItem Include is the path to where you have placed your Sitecore binaries.
Put the dlls in a different directory. You will probably not want them as part of the project. Reference the dlls from the new directory. When you compile the dlls will be copied to the bin directory.
I work with lots of projects and keep a bin directory at the root of my projects to store 3rd party dlls for exactly this reason.
Example directory structure:
MyProjects
- bin
- 3rdParty.dll
- Project1
- Project2
- ProjectN
This allows all the projects to have a well-known reference location for 3rd party dlls without having to copy the dll into each project.
If you are working on a team you should all agree on a standard directory structure for your code. This will save you lots of headaches beyond just this.
In case of Sitecore, just make sure to set the property of the reference(Sitecore.Kernel, Sitecore.Client, etc):
'Copy Local' = false.
I believe that if you put these files in a subdirectory other than bin, Visual Studio won't remove them. You can still make the new subdirectory part of your deployment.
Well, I'm going to go ahead and answer my own question, since it seems like the simplest answer so far. I marked the assemblies in question as Read-only. Now they don't get cleaned.
Still wondering why most of the others don't get deleted.
Right now I'm working with an ASP.NET website that automatically generates images and stores them in a temporary folder. When working on my local system these go going into a temporary folder that gets picked up by Visual Source Safe which then wants to check them in. As such, I am wondering if there is a way to just exclude that particular folder from source control?
I've done a bit of reading and found that there are ways to do this for individual files, but I haven't found anything yet about an entire folder.
I think you've found one of the main reasons MS went back to projects in VS2008 and in MVC.
It's been a long time since I've used VSS (mainly because it's really out of date now), but most source providers let you exclude files and folders as a setting of the provider, rather than the project under control.
If you can switch to a Web Project rather than a WebSite then do so, otherwise I'd look at updating your source control provider, as this sort of exclusion is easy with Vault, CSV, SVN, Git, VSTS and so on (to name but a few).
Are you using ASP.NET Website or ASP.NET Web Project? The difference is significant enough to solve or promote this problem.
Websites, love to scan the file system and auto checkin.
Projects, checkin only what you tell them to.
Also Visual Source Safe is pretty out dated, most recent source control systems allow you to do what you are asking. SVN and TFS 2008 SP1 do from my experience.
You can also try to right click and pick "Exclude" on the folder, but in the case of a Website I believe this renames the folder.
I'm not sure if this is an option for you, but if you exclude your temporary folder from VSS (delete the folder inside VSS using the VSS UI), the files that go into it should not get "picked up" again.
If you perform operations on a parent project of the temporary folder, you may try cloaking the folder.
http://msdn.microsoft.com/en-us/library/x2398bf5(VS.80).aspx
I would suggest emptying/deleting your folder from your website. Have your website on startup create/verify the folder, and on shutdown to clean it up and remove anything in it. This can be DEBUG code only (wrap in #if DEBUG) if so needed. Also add a build script to your project that does this every time it is built also.
Could you just make your application write to a temporary folder that is outside of your website?
e.g. in C:\tempfiles
VSS shouldn't be able to pick it up then.