Class file Conflicts in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ is preventing me from building the solution. Even though I try emptying out the folder, each time Visual Studio starts the build process, it brings in the class file in to the temp folder with the same folder name. If I restart the machine or leave it overnight, project build without error. Is there anyway to tell Visual studio to delete/ignore/clean any lingering class files that could be in the temp folder?
Clean solution option in VS doesn't work either. Class file in conflict are from the App_Code folder.
Adding this as an answer here directly: move the temp location for easier cleaning or a pre-build event
<system.web>
<compilation tempDirectory="d:\TempASP.NETFiles\">
...
</compilation>
</system.web>
Source was the SO answer, which lead to this:
http://blog.cwa.me.uk/2007/10/15/relocating-temporary-aspnet-files/
Clean, Close all instance of VS, delete the temp files, empty recycle bin, throw pinch of salt over left shoulder. start VS and rebuild all.
works for me at the odd times this happens
Check that you have not compiled DLL file and not compiled equal class in a project.
Use a pre-build operation on the project to make sure the folder is cleared, it's possibly IIS auto-compiling your app before serving it.
I think it's that you have two class names that are the same: One in your APP_Code and another class as the name of a user control or page.
I have faced the similar kind of issue in my project. The files were facing infliction between the files having same name from the current project and an another project. I have resolved it by deleting the files from my project's bin directory whichever i don't wanted.(Still if the problem is not resolved, delete the unwanted files & temporary files from "Debug" and "Release" folders.). This worked 100% in my case.
My problem was that this error was popping up when deploying in Azure using pipelines. Looked into the "Temporary ASP.NET folder" to clean it up, but it was empty.
To fix the issue I packed the class into a namespace and updated the references to use the full Namespace.Class type.
Related
I am new in mvc and c# and I can't solve following problem:
I am trying to create a folder named "Items" in solution folder.
I have tryed to use CreateDirectory method:
Directory.CreateDirectory("~/Images");
But it didn't work for me - folder wasn't created ..
Partly working solution was to create a folder by :
Directory.CreateDirectory(Server.MapPath("~/Images"));
"Items" folder was created, but it is not included in the solution:
How to create folder in solution directory so that it is included in project ?
(I needs to by done by code not by hand)
You need to understand what solution and csproj file is used for
In general, they're being designed and used for development with Visual Studio, and once the project is compiled, all these files will be ignored and excluded from the deployment package
Directory.CreateDirectory(Server.MapPath("~/Images"));
The code above simply create the directory if not existed yet in the deployment package at run-time, so you won't see it in your solution unless you run the project locally (either debug/release mode, it does not matter here). However, everything will run normally in hosted environment (ex: IIS).
For your information, here's the brief of what solution and csproj is
solution (.sln) file: contains information to manage one or many individual projects, contains build environments (for each project), start up mode (useful when you want to start multiple projects in one run), project dependencies and so on. Take a note that VS also read from suo file (solution user options) which is used to defined user-custom preferences (you should not include the .suo file in the version control, because it's custom settings)
csproj file: define the structures of project, what the namespace is, what is static folders, embedded resources, references, packages, etc.
Lastly, if you create the folder manually, VS will auto include that folder into deployment package AND csproj, but depends on the file type, you might need to change the Build Action and Copy To Output Directory in file properties.
Hope it helps.
A deployed web application on a web server doesn't have any notion of Visual Studio solution or projects. So the Directory.CreateDirectory(Server.MapPath("~/Images")) is the correct way to create a folder inside your web application at runtime but we cannot be talking about including it into a solution because this hardly makes sense in a pre-compiled web application. If you create the directory on your local development machine, you could always manually include the folder to the corresponding .csproj file, but at runtime this will not make any difference whatsoever.
The reason I wanted to create a folder (if didn't exist) was to make sure it exits before I try to store image in it.
After reading posts here and a few google searches I have concluded that the proper way to handle image upload would be
To create (In my case) folder "Images" by hand to be sure it exists
Then storing uploaded img in existing folder:
string path =Server.MapPath("~/Images/"+ UploadedImageName);
file.SaveAs(path);
I'm writing a C# project which I want to compile both under VS2010 and VS2012. I want to have two different .csproj files for that, even though VS2010-project can be directly included in VS2012-solution. I want two different project files because of different target .NET-versions.
Additionally, I want both projects to be named the same within different solutions for VS2010 and VS2012. The both should share the same .cs-files and, possibly, some resources.
Easy task? Strange thing, but I don't know, how to do that properly.
First approach, doesn't work: name project files as MyProject10.csproj and MyProject12.csproj, leave both in the MyProject folder. But in this case they are displayed in solution as MyProject10 and MyProject12, not simply MyProject. If I rename one to MyProject in solution explorer, it automatically renames the corresponding project file.
Second approach, works, but has drawbacks. Move project files into different subdirectories, named VS10 and VS12, manually change include paths in .csproj-files, adding ..\ as a prefix. In this case I see strange shortcut-like arrows under the icons in solution explorer.
The only bad thing for the second approach is that when I add new files in the project using solution explorer, this file is placed in the VS10 subdirectory, not in the root project directory. But it seems like project directories for .csproj-files are the directories containing the file by design, and I use the dark side of the force which I really don't want to do.
Any better ideas?
Worth giving a try is changing the name of the output assembly in both projects to one and the same. The project files are still going to be different, but the output assembly will be with same name. Also be carefull where is the output directory. I think this way you can sovle your problem.
I have an annoying error that's been popping up, and I don't know where it is coming from. The error is:
Error 31 Unable to copy file "app.config" to "bin\Debug\Framework.Tests.dll.config". Could not find file 'app.config'. Framework.Tests
The problem is, I don't have a bin\Debug folder anywhere, and it does not say from where it is trying to copy app.config. Double clicking on the error doesn't bring me to any code where it is trying to copy, so that doesn't help me either. So I don't know where I should make the app.config.
How can I find this out?
You have added a reference to a file called app.config or Visual Studio did this for you. The file does not exist on the disk, presumably because after adding the reference you later deleted the file.
Search for the missing file in your Solution Explorer, and either delete the reference or create the file.
It is most likely in the root folder of one of your projects, and should have a yellow triangle warning icon showing that the file is missing.
In an MSTest project the app.config is the one that you would like to provide any calls to the ConfigurationManager class.
It resides in the root of your test project.
The bin\debug folders will be created once the project compiles for the first time. Show all files in the solution explorer should help as they are not (and should not) be included in the project.
HTH
You probably do have a bin\Debug folder beneath your project folder, being the build target folder created by Visual Studio when you build your project for the Debug configuration.
My guess is that something (a test framework perhaps) still has the DLL file loaded, so Visual Studio can't delete and replace the existing Framework.Tests.dll.config file with the contents of your app.config. [Note: the project build action for app.config files is to copy it to the target folder renamed to match the executable with an extension of .config appended.]
I have several ASP.NET web projects and their Output folder are set to "C:\Builds\[ProjectName]bin" (instead of the default "bin\" folder). This makes "F5" Debugging not working because the ASP.NET Development Server expects the "bin" folder under the project folder.
I then changed to use Local IIS Web server (http://localhost/webproject1") and manually updated the vdir physical path to my custom output path. However the VS2010 will not load the csproj because it detects the url is already mapped to a different folder location.
I know I probably shouldn't change the Output folder. But wondering if there is an easy way to workaround this? The goal is to make "F5" debugging work with custom build Output folders.
Update due to Aristos' answer:
Thanks Aristos. Unfortunately that won't solve the problem. All my projects already use the Project Reference, so all the reference dll's are correctly copied to the output folder. The reason why F5 debugging does not work is because the output folder is not the normal "bin" sub folder, but in some other path say C:\BuildsOut\Foo\bin.
It seems that in order to use F5 to debug the web project in VS2010, it has to use the default Output path "bin". If you change that, then F5 will not work and even worse your project may not even load.
Ian,
I have been frustrated by the same problem. I finally gave up and put this dirty little fix in place. I added the following to the "Post-Build" event:
copy "$(TargetDir)MyWeb.dll" "$(ProjectDir)bin"
copy "$(TargetDir)MyWeb.pdb" "$(ProjectDir)bin"
This at least lets me debug the site properly and hit my breakpoints.
You place them all on one single solution, you set as the started project your web project, and then you add on your web project the rest dll as reference (right click on web, select on menou "add reference", and automatically gets the latest version of dlls and place them on bin.
Now when you ress F5 if anyone dll project needed is automatic build it, then run the subproject with the new dll inside.
Delete all items in your bin folder for the solution in question, shut down your system and restart. This fixed it for me at least.
I have a solution made up of multiple projects which have various dependencies on each other. When I build the project/solution, it creates the DLL assembly files in the Project\bin folder(s) as it should. But when I run the program, it copies everything to the temporary files folder and runs it from there:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ApplicationName
So now there are identical DLL files for each project in the bin folders and in the temporary files folder, where it's being run from. The problem is that I have references to the bin directory(s) hardcoded into my projects in a couple places, so when it looks there, it comes back with a DLL mix-up and errors out. How can I get Visual Studio to run the assembly files from the original bin directory(s) instead of duplicating them and running them from the temporary files?
P.S. Please don't tell me to change the hardcoding - there are reasons why it has to stay as it is; that's why I'm trying to figure out how to run from the bin.
Thanks
This is known as Shadow Copying, and its a design feature. Particularly for ASP.NET sites, it enables domain assemblies to be updated without unloading the application domain, which is important for ASP.NET sites which are designed to run continuously. I would really recommend leaving it on, and re-assessing the requirement for use of the \bin directory.
If you really want to disable shadow copying, add the following to your web.config file:
<hostingEnvironment shadowCopyBinAssemblies="false" />
The side-effect of doing the above, is that your assemblies in your \bin directory will be locked during the lifetime of the application.