I have a class library project which contains some content files configured with the "Copy if newer" copy build action. This results in the files being copied to a folder under ...\bin\ for every project in the solution. In this same solution, I've got a ASP.NET web project (which is MVC, by the way). In the library I have a static constructor load the files into data structures accessible by the web project. Previously I've been including the content as an embedded resource. I now need to be able to replace them without recompiling. I want to access the data in three different contexts:
Unit testing the library assembly
Debugging the web application
Hosting the site in IIS
For unit testing, Environment.CurrentDirectory points to a path containing the copied content. When debugging however, it points to C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE. I've also looked at Assembly.GetExecutingAssembly().Location which points to C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\c44f9da4\9238ccc\assembly\dl3\eb4c23b4\9bd39460_f7d4ca01\. What I need is to the physical location of the webroot \bin folder, but since I'm in a static constructor in the library project, I don't have access to a Request.PhysicalApplicationPath.
Is there some other environment variable or structure where I can always find my "Copy if newer" files?
Assembly.Location does indeed point to the location of the assembly after it has been shadow copied.
However, that MSDN page states:
To get the location before the file has been shadow-copied, use the CodeBase property.
Related
Now I have seen this question before on SO in a variant ways, but surprisingly not in this form:
I have a solution with multiple web services (projects) that need to talk to each other. After publishing each of these web services might end up on a different machine with a different database. To tell each web service where all other web services are, I want to maintain a single config file during development.
I would like to expect that after publishing the config to be present in each published project. And I would like to expect the config file to be editable after publishing, so I can swiftly migrate a certain web service and then just edit all config files of the other web services.
I don't want to do this in the database, for the config file its self should also hold connection settings to the database(s).
I came across the following ideas/thoughts/questions:
I have a dll project called 'common' that is referenced by other projects. Let's give that one a shared.config and build a class in that project that can be used to read out the shared.config by doing System.Configuration.ConfigurationManager.OpenExeConfiguration("shared.config"). Just need to make sure the shared.config will be published along with the DLL.
I would favor this solution, as it would also let me keep a web.config inside each project having just the project specific settings. And have the shared.config having the shared settings. But I read on SO that this should not be considered lightly and could have some unwanted side-effects, like file-access-issues; though I wonder if this would apply to my case. Also I would like to ask your help here on how to actually realize this as I don't think Visual Studio supports app.config for DLL projects out of the box.
I also thought about creating a shared.config file in the Solution Items. Then linking that file inside each project. And in the Web.config of each projects, add: <appSettings configSource="shared.config" /> pointing to the linked file in that project.
Though I cannot find any reason why not to do this, first implementation failed. It seems (at least during development), c# cannot find the linked shared.config file. I'm guessing linking files is not done instantly nor maintained after creating the linked file, but the file is only copied to the projects WHEN I do a publish. Thus leaving the file missing during development. Is this correct?
The config files are app specific. This mean that you can add a config file to a class library but the file will then by used by the app (windows service, webservice and so on) referencing the library.
Same thing for external configSource, this are app specific as well and need to be included withing the project using it.
So if your solution is composed by 2 projects you then need 2 config files. One for each project.
While for a windows based application(services, winforms) the expected folder for config files is the bin directory, for web based projects this will be the directory is the root folder of the virtual directory.
This said, using a shared config file looks the easier solution (and you don't have to copy the app.config from the class library for each project). Here are the steps :
Create a solution folder.
Add the config file to it.
Add the file as a reference for each project needing it. Right click the project and Add existing item - > Choose the file and Add as link
Ensure the file is always copied by setting the copy option (properties of the file) with Copy Always.
At this point you should have the config file deployed into your project directory everytime you compile the solution.
EDIT:
I'd avoid looking into the bin for config files within a web app, the
convention is that file should be in the root, so I would avoid the
first option.
Linked files end up in the bin after building the project. Try the same steps for importing the file but this time simply add it (not as link) and it will be deployed as content in the root of your site, so it can be always available.
If your hosting in IIS it is possible to have a single web.config file at the root site level but Giorgio is right in that app.config files are app specific. it is possible to use custom build steps to automate the copying of config files across multiple projects so personally I would go with that.
This actually drove me a bit crazy. In the end I fixed it like this:
Created a Shared.config file in the dll project 'common', having the contents look like any ordinary web.config/app.config.
Set the file to be Content and Copy Always, so it would surely be copied out to all projects that reference project common. (Though the config file will indeed end up in the bin folder.
Created the class SharedConfiguration inside the common project. The really tricky part was having to use OpenMappedExeConfiguration() , and getting the path to the executable directory (including bin, and without file:// in front of it).
Now when I want to access a setting from the shared settings, I do SharedConfiguration.instance.AppSettings.Settings["CubilisEntryPointUrl"].Value.
(I cannot use SharedConfiguration.instance.AppSettings["CubilisEntryPointUrl"] directly because of this issue)
.
public static class SharedConfiguration
{
public static readonly Configuration instance = GetConfiguration("Shared.config");
private static Configuration GetConfiguration(string configFileName)
{
ExeConfigurationFileMap exeConfigurationFileMap = new ExeConfigurationFileMap();
Uri uri = new Uri(Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase));
exeConfigurationFileMap.ExeConfigFilename = Path.Combine(uri.LocalPath, configFileName);
return ConfigurationManager.OpenMappedExeConfiguration(exeConfigurationFileMap, ConfigurationUserLevel.None);
}
}
When building ASP.Net projects in Visual Studio (version 2015 Community), website configuration files (e.g., Web.Config) are copied by the build process into the bin folder alongside the compiled .dll file, and renamed {assembly}.dll.config.
This occurs despite the Properties Window for the Web.config file being set with the following parameters:
For our solution, this second copy of the file is not necessary, nor used in the {assembly}.dll.config form found in the output bin folder.
I would like to know what is necessary to prevent Visual Studio from making a copy of the configuration file and placing it in the bin output directory.
Having sensitive configuration settings in two places (Web.config in the root directory, and {assembly}.dll.config in the output directory) is problematic from a security standpoint.
To deploy your app, Publish your application. This way, only the necessary assemblies/files are deployed. Your published /bin folder will reflect this (will not have the "duplicates" you mention).
Security: depending on what you're after, you can
separate "sensitive" information from web.confg into their own files. This usually is only for keeping such from online repositories (TFS, Git, etc.) - by excluding the file from being in source control
e.g.
<appSettings file="AllMySecrets.config">
....
Use encryption
Hth.
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);
In an Visual Studio environment, Project A (ASP.NET) references Project B (C#) in my solution like this:
Solution
├─Project B
│ ├─data.txt
│ └─process.cs (a class BB with static initialization new FileStream("data.txt"))
└ Project A (referencces Project B)
├─bin
│ └─data.txt (copied from project B each time project B changes)
└─Controllers
└─mycontroller.cs (references the class BB)
The problem is that when I run the application, the working directory is C:\Program Files (x86)\IIS Express\, so that data.txt cannot be read from the compiled version of process.cs which is in bin.
For the moment, to solve the problem, I manually copied data.txt to this folder, but this solution is not viable.
Note that changes to B must be coherent with other projects depending on B, which are not all ASP.NET project.
What changes should I make so that data.txt is accessible from my project without relying on me to copy the data.txt file to the IIS Express directory?
I would like to port my program to Azure Online and I cannot rely on this method. Thank you for your help.
Other linked answers:
This answer is ASP.NET - specific, I cannot add server.MapPath because the project does not know about it.
This answer references project paths, but does not give me an hint about how to modify them.
"Note that changes to B must be coherent with other projects depending on B, which are not all ASP.NET project"
Not sure what coherent would mean to you in context of other projects which depend on project B...
But following options come to mind -
Embed data.txt as a resource in the assembly generated for project B. Project B, can then read the file as a resource (This assumes, file contents do not need to be modified after the build)
See ResourceManager class for handling resources embedded in assemblies.
http://msdn.microsoft.com/en-us/library/system.resources.resourcemanager(v=vs.110).aspx
If it works for all clients of Project B, scan sub-directories for the file.. This is more hackish.. but really depends on the scenarios for project B.
Ensure that data.txt is being deployed somewhere. Then, make your library take the path to it or the base directory path as an argument. The caller of the library is the application which has concrete knowledge of how to obtain the file's path.
Or, embed the .txt into the DLL as a manged resource.
To me your problem is not about copying the file - but its location. A shared file should be kept in a shared / central location accessible by all applications. In your current situation this could be (and this isn't exhaustive)...
Database Blob
Explicit File Location
Online, retrieved over HTTP
Online, retrieved over FTP
Networked location
Running a small TCPIP server between the programs so that one acts as the source and child processes request the file.
In respect to porting your application to Azure, Azure provides a BlobStorage along with functionality to access the file in an unsecured and secured manner (see Shared Access Signatures).
HTH
Can't you just configure your project B with your project A ? I mean giving the path of your txt file to some static field of a configuration class from project A to project B.
I'm having a problem with a third party C# class library:
The given .net dll requires additional files to be in the same directory than the .dll (config files etc.).
When I load the library as reference into asp.net project everything works smoothly until first call to the library. I get exceptions from the library saying that the required files are missing.
Now the question is where should I put those required files into? I've tried obj/debug/, bin/ and including the files in the project and selecting "Always copy to output directory", but none helped.
I guess it's something to do with IIS and its way of handling the reference/additional files?
Edit: It's working fine in Windows Forms application, but not in ASP.NET web application.
You can view source code of external class library with iLSpy or Reflector to find how exactly additional files are referenced.
It's can be an application execute path (so it must be IIS shadow copy directory) or GAC.
For that you need to read the documentation. The method throwing the error should be expecting the file in some other folder other than bin, debug or obj.