I have a site which is live and I only have an FTP of that site so I just want to make some changes but I found that it is a compiled site and if I have to make any changes then I have to make modification and compiled it again and upload the file.
But when I check the Bin folder then I can see that there is only one dll file is created which is named as mysite.com_deploy.dll which is combined dll file.
So I don't know how this has been published or compiled?
Can anyone let me know about this?
Your question is a bit odd... if it has a DLL then it has been compiled, one dll for the whole site or one dll per page is a compile time option.
How you publish your site (how you move the compiled code to the web server) is another matter.
Which begs the question what is your real issue?
Try right clicking on the web deployment project -> properties and in the Output Assemblies : tick the option "Create a separate assembly for each page and control output" if you want multiple DLLs for one project. Taking this route can cause potential issues with naming of DLLs if you want to replace one.
Is that what you wanted?
Try right clicking on the web deployment project -> properties and in the Output Assemblies : tick the option "Create a separate assembly for each page and control output" if you want multiple DLLs for one project. Taking this route can cause potential issues with naming of DLLs if you want to replace one.
Related
I'm still learning the basics of how VS2010 sees the world. Apparently, you can optionally "include" a file in a project. I'm a bit confused by this: If a file is version-controlled, AND the file is within the project directory, shouldn't it implicitly be "included" in the project? If not, what's the use case where a version-controlled file in the project directory should NOT be included in the project?
=== Addition ===
Based on the answers I've gotten so far, maybe I should rephrased my question: What does it mean for a file to be "included" in a project?
A project needs to know about files in order for compilation and distribution to occur. Just because you have a file that's under source-control, doesn't mean that it will be compiled if the project is unaware of it.
Also, you may want to include files as part of a distribution package. We do this quite often for our web projects that we distribute using web app gallery.
Conversely, you could have documentation or sql scripts that you version control, but do not want them to be part of the project.
EDIT: In answer to your update, what it means for a file to be included in a project is that the file is actually added to the .csproj or .vbproj file and will be used during compilation and/or distribution. VS does differentiate if the file is Content or if it needs to Compile it. This can be seen by clicking on the file in Solution Explorer and looking at the Build Action property.
No, you don't want random files that happen to be in the project directory included in source control.
We do sometimes put documentation (pdfs) or drawings/schematics in the project folder and under version control but you don't need them inside the visual studio project (especially when they are not being distributed because they are for internal use only).
Excluding the file from your project can be useful if the file is related to the project but not necessarily needed in the solution.
Example
If I need some test XML for an application that i'm writing; that is designed to normally be pulling this from a WCF service, it can be useful to keep that file in the directory for a development environment where I use IO to get the XML for testing, but I don't necessarily want it in my solution which is source controlled.
When you exclude a file from a project is no longer compiled or embedded, then when you want to include it again you can do so without having lost your settings.
If you e.g. copy a file (containing a helpful class which want to have in your project) into a folder of your project, then you will see ... nothing. You have to check the option "Show all files" of the solution explorer and the copied file can be seen, but it is still "greyed out". No you can choose the menuitem Include in project and that file will be integrated in your project and a pending change (add) for your source control is added too. Visual Studio doesn't include all files it can find in the project folder automatically to the project - and that is a good feature.
One of my colleagues explained to me a scenario in which a version-controlled file should NOT be part of the project. Here's the idea:
A developer writes some new code.
The code is experimental, and not intended to be part of the normal build.
The easiest way to exclude the file from the build is to NOT include it in the project, but still version-control it.
This way, the file can be shared with other developers, but not break the build.
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.
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.
It's a beginners question, but...
Image of dll reference and dll included in project file http://a3.vox.com/6a00c2251e5b66549d00e398ca81eb0003-pi
If you look at the image above, there is the "Bass.Net" dll added as reference and also directly as file in the project.
Can someone tell me what's the point of doing that?
No reason, really. It could be that Visual Studio is set to display files not in the project (hard to tell from the picture) and the dll's happen to be in the main directory. The text is pretty clear that the extra files are
bass.dll
bassenc.dll
lame.exe
The .net one happens to be with the others in the same directory and you need to add it as a reference.
Within Windows, a DLL is a dynamic link library, which packages a set of programmatic functionality together. In this example, bass.dll exposes the features and functionality relevant to audio processing through this file (and any files it depends on). In order to use this functionality, you need the reference in the solution, so that Visual Studio can link it at compile time. The DLL will then typically be copied to your output directory when the application is built.
That's all that is necessary to get the code to work properly, the rest is really just preference or convention. Some people prefer to have all the files that exist in the project directory in the solution, so that the Solution Explorer reflects the file system. Typically you will want to have libraries your application depends on somewhere in your solution directory hierarchy so that the entire application is packaged together (making source code control use easier, for instance). You won't want to put this library in the BIN directory or any directory that Visual Studio generates, though, to avoid accidental deletions. In any event, having the reference is the important part, the file being in the project or solution is not necessary.
Typically, you'll want to keep external libraries out of your source directories, though, so I wouldn't actually recommend this structure. I tend to use a structure like this, but, again, this is all preference:
Source: Source code and project files
Libraries: DLLs
Support: Miscellaneous code or projects, but not actually part of the application (perhaps deployment scripts)
Having those in your project and output directory allows the final executing code to reference them without any issues running on different machines.
It sounds as it they put the reference dlls in the project directory, reference them from there, and also include them in the project. That way, when the project directory is copied, the reference dll will be copied with it. Additionally, if the reference dll is missing, the project will complain in Visual Studio.
If an assembly (Bass.Net.dll in your case) contains classes you want to use, you must add a reference to that assembly to your project.
No point the best thing to do is get all your dependenicies and store them in a seperate folder and only reference them do not copy them to your solution ;)
It's really hard to guess why someone else did something, but if I really had to guess, I'ld say that the guy thought to embed the necessary dlls as resources to be sure it was availale to the application. I have seen this technique used to embed fonts or sounds and am not sure if it works at all with dlls; but it's just a guess.
Of course the best way to be sure the files were available would have been to create a deployment project, with Visual Studio or some other installation tool loke Wise or InnoSetup, just to name a few.
This actually might be a good idea in a lot of circumstances. In my opinion their are 3 types of dependencies
Assemblies from the .Net standard library. Never include those locally.
Assemblies that you expect other developers to install as part of an MSI or exe setup package. This usually means their strongly signed and have a copy in the GAC.
Assemblies that you don't expect other developers to install via an MSI or exe installer. Maybe because you have a third party or in house library not in the GAC.
In the third case, the simplest thing to do is store a copy of the DLL in the source repo.
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.