Help needed! I am new to IIS Administration and trying to host my ASP.NET Web Application.
My Web application looks similar to the one below:
I want Parent, Child-One and Child-Two to run as separate Applications and can be accessed as parent.com, parent.com/child-one and parent.com/child-two respectively.
The reason why I opted for this Project structure is to check if it is possible to Re-use some libraries present in Bin folder of Parent in Child-One and Child-Two.
Is it possible to re-use some DLLs from Bin folder in Parent, inside Child-One and Child-Two, Or do I have to create 3 separate projects?
You show a single project with some folders inside. The location of bin folders is not very relevant. More important is that there is only one References node (as with every .NET project), and whatever you add there is available for the whole project. You do that with Right-Click + Add Reference...
You don't need the separate bin at subfolder level, but if you insist on placing DLLs there then it will also work, as long as you set Copy Local to True in the References node (meaning that on Build the referenced DLL is copied to the output folder).
Visual Studio itself will always default to working with the root bin, e.g. if you add NuGet packages, then that is where their DLLs go, and you shouldn't mess with that.
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 have a main executable that runs based on settings saved in a configuration file. I want to be able to change the settings in the config file through a different executable.
Is there an easy way of building these two different executables in one Windows Forms project? Meaning that when I press build, two different EXE files get created in the same solution folder - the one that changes the configuration file, and the other that uses it.
I know that this is possible to do if I create two separate projects that use the same solution folder, but I was hoping to do it all in one step.
I am assuming that to do this, I need a project with two "Main" functions. Is this possible?
You can build as many assemblies in one solution as you like. Assemblies can result in DLL files or EXE files.
Create a solution (or open an existing solution).
Right-click the root node in Solution Explorer and choose Add → New Project and choose the project type you like to add.
Right-click the project item in Solution Explorer and choose Properties → Build → Output path. Set to the desired directory where to build it to. Repeat this for the other projects.
This way you get the following in Solution Explorer:
MySolution
MyCommonCode (Class Library, results in MyCommonCode.dll)
MyMainApp (Windows Forms application, results in MyMainApp.exe)
MyConfigApp (Windows Forms application, results in MyConfigApp.exe)
The MyCommonCode assembly contains shared code that both EXE files are using like the identifiers of your configuration file, etc.
MyMainApp is the GUI application (Windows Forms, WPF, etc.) for your main application with a project-reference to the MyComonCode project.
MyConfigApp is a GUI application for editing the configuration values with a project reference to MyCommonCode project.
After building your solution you get the following binaries: MyCommonCode.dll, MyMainApp.exe, and MyConfigApp.exe.
Update based on the comment:
One compile-run can build only one binary (DLL or EXE) per project. You can do something like the answer above: move most of the code in a common/core DLL and make two thin projects for the two EXE files which only "configure and use" the central common/core DLL file.
You can build different EXE files based on the same project using compiler defines. You can even define your own defines. But per compile-run you can only build one binary (DLL, EXE) per project - one or the other, but not both.
I'm having a "tiny" issue with my App_Code folders.
I'm learning ASP.NET and, therefore, ordered a webserver with the support of ASP.NET 4.0. I'm using Visual Web Developer to program my webpages. When I upload my website to this webserver everything runs fine.
However, if I then add another web project to my server, my App_Code folder gets all messy. The server wants all my class files in the App_Code folder in the root. Is there any way I can create subdirectories in my App_Code folder or something to keep my projects organized or am I missing the point here?
You should take a look at codeSubDirectories in the web.config
Alright I found a solution to my problem. Although most of your answers might work aswell, this proved to be the best in my case. I created a subdomain and threw all files into that folder and it worked fine.
You should try to avoid using the App_Code folder for your own stuff, especially if you're using a web application project.
Whenever you convert a website to a web application project, the process actually renames your existing App_Code directory to Old_App_Code.
See Here, even though this is specific to converting .net 2.0 apps, I believe it still holds true in 4.0 since converting a 4.0 app does the same thing.:
VERY, VERY IMPORTANT: Because ASP.NET 2.0 tries to dynamically compile any classes it finds under the /App_Code directory of an application at runtime, you explictly DO NOT want to store classes that you compile as part of your VS 2005 Web Application Project under an "app_code" folder. If you do this, then the class will get compiled twice -- once as part of the VS 2005 Web Application Project assembly, and then again at runtime by ASP.NET. The result will most likely be a "could not load type" runtime exception -- caused because you have duplicate type names in your application. Instead, you should store your class files in any other directory of your project other than one named "app_code". This will be handled automatically by the "Convert to Web Applicaiton" command. This command will rename the folder Old_App_Code.
If you have access to a hosting control panel it's probably best to configure your hosting environment with a virtual folder for your second website and run it from the sub folder, e.g. www.example.com/project-b. The first site can still be running in the root folder, e.g. www.example.com.
So both sites will essentially be isolated from each other (just like they are now isolated as two separate projects in Visual Web Developer Express). And both sites have their own App_Code folder (and web.config file).
If you don't have access to a configuration panel, most hosting providers are willing to add a virtual folder for you, since it's really not a special requirement.
The virtual folder should show up as a regular folder in your FTP folder, usually inside the www or wwwroot folder. Now you can copy your project files into that folder.
Take care to use root-relative paths for URLs in your second project, so all links will work even when the website is run from the subfolder. Root-relative URLs look like this:
<asp:HyperLink runat="server" NavigateUrl="~/Default.aspx" />
<asp:Image runat="server" NavigateUrl="~/images/logo.png" />
This will automatically go to www.example.com/project-b/Default.aspx and www.example.com/project-b/images/logo.png when the website is deployed in the virtual folder.
If you need to re-use code from one site in the other, it's typically best to move such code into a separate Class Library project type, and then add a reference to that project to each website project (right-click the website project, choose Add reference..., then select the Projects tab and select the Class Library project).
We have a solution comprising of a windows application and various library files. Not all of the library files are referenced by the main windows application however we would like to have all the library files included in the output build folder "bin".
Obviously one solution is to simply reference every single library from the Windows application however we would like to avoid any unnecessary referencing.
How can we include additional files into our build folder?
This is a C# project.
You can always use the pre-build or post-build events in the project settings to copy the additional files.
You can do this simply by doing a bunch of copy source target, or you could even be fancy and write an nmake file. You do have to maintain the list of source files however...
Edit:
One other thought. Your assumption is that this is "unnecessary referencing". However, if your application depends on these assemblies to run, whether or not they are compile time references, then don't these dependencies become "necessary" references? In that case, isn't adding them as references and letting Studio's build system work for you the best (and simplest) approach?
The solution was to change the build location for all "libraries" within the solution to the main output "bin" location. The main Windows application only references the libraries that it depends upon however all the libraries are built to the one "common" location.
Thanks to Nader Shirazie for help with this question.
I have a annoying build process from using System.Addins API with ClickOnce. Using System.Addins requires a specific directory structure, and the main project does not reference the adapters, view, and contract directly, which doesn't work well with the ClickOnce architechture.
The annoying part with the build process is that I have to copy, via post build event, the .dlls from the add-in components into the directory of the main app project, then reference those files manually from the main project, so that ClickOnce will include them. Firstly, this takes 2 iterations of build to get it to build correctly, secondly, it interferes with source control (I have to exclude the copied add-in dll files from source control or any changes made to them would require checkout).
So, my question is, is there a way around this hack? Something more elegant?
I can't fully answer your question, but it appears you are creating ClickOnce deployments through Visual Studio. I would ditch that method and use MageUI instead. It's a stand-alone executable that can be found in the framework SDK that will generate your application and deployment manifest files. It comes with a gui version (mageui.exe) and a command line version (mage.exe).
Mage may not get rid of your post-build event but it should do away with having to reference the files to get ClickOnce to see them.
Thanks for your input, I am currently doing it the way you mentioned; creating the folder in my project, and include the dlls that I need. It works, but it's an ugly solution, and it interferes with Source Control.
I'm aware of the limitations of ClickOnce, I was hoping there may be a way around it. For example, I read somewhere that I can use deployment projects to create the appropriate dependencies needed in a specific structure. The problem with that is once it is deployed to the public, there is no easy way (within ClickOnce) to update those dependencies.
The solution I use is to have a single output folder for all projects. Every project puts it's own files in the correct subfolder. The application bootstrapper project puts his dlls also in the output (root) folder. When you then create a click-ones for the bootstrapper, it will take all the content from the output folder.
The hardest part is to actually get all the dll's in the right place (and have every dll only once)
I solved this problem by adding the pipeline assemblies as content into the main solution structure.
To do this, change the output folder from (/bin/debug /bin/Release) to something else. I used ../lib otherwise you would get a visual studio cannot reference this file error.
Create the pipeline folders in your main solution
\AddInSideAdapters
\AddInViews
\Contracts
\HostSideAdapters
Right click on each of the folders and click "add existing item" change to view all files and then browse to your ../lib (or wherever you have the output set) and then pull down the add button (click the down arrow) and click "Add as a Link".
Right click on each file and set it to Content.
This will create a refresh file pointed to your assemblies and they will be included into the clickonce manifest.
ClickOnce do not let you install the software where you want. It will install the binary and dlls in the documents and settings. You can in your project properties go in the Publish tab and select Application Files to select additional file to Include. If the System.Addings require dll in a specific folder relatively to your assembly, you might just create the folder in you project and includes from here the dlls. This might works. If not, I do not have "hack" or other solution, clickonce is great but limited with some functionalities.