I have a web site project with a lot of files, it has become really slow to build. What I want to do is to create a web application project, and in Explorer add all the files to it, including the Bin folder. In Visual Studio I will not add these files (Show All Files will show them), only new files in one new folder that I am going to work on.
There are several assemblies in the original Bin folder that I need to reference in the web application project. Also, I will include the original web.config file.
So what way am I going to regret this in a few days?
You wont have support for all the old stuff when using the Visual Studio Publish feature (I assume you wouldn't anyways).
I also would assume you wont have access to what is in your App_Code from your new web application project.
I will add an answer myself.
A rebuild in Visual Studio will clean out the bin folder...
Related
I just simple know that is a published project, but how to open that file as a project? Here is the story, I got a file from a contractor with all the project and the pages and I would like to check the code and run the project from Visual Studio 2017.
Sorry about my ignorance and thanks in advance.
You can't.
What you can do though is create an ASP.Net Project (e.g. .csproj) and then right-click on a folder or the root of that Project and select "Add Existing Web Site...". This adds your site to that solution.
Note that .publishproj projects ("Web Site" Projects, aka "Web Applications") are not really compiled/built. (Though they can be pre-compiled, but that's not the same thing).
Web Sites are "published" not "built". Note that publish profiles (.pubxml) files are stored in /App_Data/PublishProfiles folder and work very much the same as .csProj files. In fact MSBuild will recognize some of the same elements, such as <task> and <using>. You just have to manually add them.
We have a main web application that references several other projects. Do you check-in .csproj/.sln files into source control? If so, do you use these files for msbuild or do you just include *.cs to build your dll? Does ILMerge help in any way with performance?
You should aim to check in everything that is needed so that someone can take a fresh install of Visual Studio, do a checkout, double-click the .sln file, build and be on their way.
.sln and .csproj are a no-brainer, in my opinion: what happens if you add a new file to the project: everybody would have to manually add the file to their project files if you didn't commit the .csproj file.
ILMerge - no. Not for web applications. Not for the rest either.
Checkin? What about letting visual studio handle it. Now, in general - source control without all relevant files is garbage ;) So, it should include stuff like the project and solution.
I am working with Team Foundation Server and Visual Studio 2008 for the first time. I had a web site project that was done with Visual Web Developer Express, which I have converted to a solution containing a Web Application Project, setup for TFS source control, etc etc.
TFS was having issues checking in/uploading some of my referenced DDLs, specifically AjaxControlToolKit, saying things like /bin/AjaxControlToolKit.pdb couldn't be found. I removed the reference, deleted everything it had in /bin (it had created lots of folders like /ar, /cs, /de, etc etc along with other files like /bin/AjaxControlTookKit.dll), then re-added the reference to AjaxControlToolKit. It will now upload, and works fine locally, but it didn't re-create anything in /bin. I have other references that work fine and have info in /bin (ie: /References/LinqKit.dll and /bin/LinqKit.dll) I cannot do a build on the server yet, but locally it works. So, will this work when its built on the server? Why didn't it recreate anything in the /bin folder? Is that something to do with Visual Web Developer Web Site vs Visual Studio Web Application/Solution? Any info is appreciated! Thanks.
References are references, not copies of the assemblies. Where are the assemblies you're trying to work with?
Typically, you'll want to check in third-party assemblies that you are not maintaining source. You'll then want to change the file references to point to the version from source control.
Of course, this means that all your developers and build machines will need to maintain the same folder structure on disk.
I am just getting started with Silverlight and have recently added a Silverlight project to an established solution. In this particular scenario my solution included an existing ASP.NET web site (not application) which Visual Studio kindly offered to integrated my Silverlight application into, which I accepted.
So everything is fine and all, and the Silverlight XAP is being copied to the web site's ClientBin directory. Now I have decided to start a new ASP.NET MVC web application that will eventually replace the older (non-MVC) web site. But I cannot for the life of me figure out what Visual Studio modified to get the XAP to automatically appear in the web site's ClientBin on build, so that I can reproduce that on my MVC site.
So my question is essentially, what are the manually steps for getting Visual Studio to autocopy a Silverlight application's XAP to a newly added ASP.NET MVC web application?
You can do this through the properties of your web project. The Silverlight tools for visual studio add a new tab to the properties of web projects named "Silverlight Links".
Add a reference to your Silverlight project here, with the folder where you want it, and visual studio will make the copy for you.
The copying of the XAP to the ClientBin is a MSBuild task. If you're using a standard ASP.NET project template it can be found under the Silverlight Link section.
For everything else you might be able to figure out the name of the MSBuild task and add it to your ASP.NET MVC project. The easier solution would probably be to use a custom post-build event on the APS.NET project to copy the file.
There is no "magic" happening, oter than copying the XAP file from the BIN directory of your Silverlight project to the ClientBin of your web application. It doesn't even have to live inside the ClientBin directory - you can copy it to any directory, or the root of your site.
Update: The recently released Beta 1 of ASP.NET MVC includes support for Silverlight projects, so you can link it to your ASP.NET MVC application the same way you do for regular ASP.NET applications.
Go to the property pages of your Silverlight application, Choose Build Events Tab, Enter following line in Post-Build events command line:
copy $(TargetDir)*.xap $(SolutionDir)<youar web solution folder name such as app.web>\ClientBin
Now onwards, on each successful build, the xap file will be copied automatically.
This is a somewhat older post so it probably has changed... in my Visual Studio under the web project there is a tab called "Silverlight Applications". There is an add button there for existing projects that you import into the solution and you can add them and choose to place the xap in the ClientBin or anywhere else. Not sure if you have to have the SDK installed to have this tab. I have it installed so you may have to. I don't do MVC, so it may be different for MVC projects, I don't know.
I have finally finished my web site. I published it, and I was surprised at the results. Although the App_Code compiled into a single DLL file, every page's code behind compiled into its own DLL file. How do I make it so that it is one DLL file?
Also, is it possible to compile everything (SubSonic, AJAX, etc.) into that same single DLL file?
You might prefer to use the web application project style for that.
You can use ILMerge to merge assemblies into one.
The way we do it is by adding a deployment project to our site:
http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx
To accomplish this you will have to covert your project into a Web Application Project (Supported in Visual Studio 2005 SP1 and Visual Studio 2008).
The process of converting is not that hard, but you will need to move everything out of the app_code folder, as WAP (Web Application Projects) projects do not have code inside app_code.
Once you do this, everything inside your project is compiled into a single DLL file, any external assemblies are still contained in their own DLL files though, but there are options around that as well.
We use build scripts for our websites and run the aspnet_merge.exe from the command line. Here's the MSDN page: http://msdn.microsoft.com/en-us/library/bb397866.aspx