Say I want to create vb.net application in Visual studio 2005.
What is the difference between File->New->Project vs File->New->Web Site?
EDIT
I am aware that when using New->Project there are many more options available but if one wants to create just .net web application, would it make a any difference what option you choose?
Here's a good link about WAPs (web application projects) and the differences between WAPs and website projects.
In 2003, your only option (if I recall correctly) was the WAP. 2005 introduced the concept of website projects, where all your code is uploaded to the server and compiled into DLLs on first access. This allows you to easily change your code without having to compile and publish the dlls.
Not a lot of people liked this new way of doing it, so MS created an update to allow for 2003 style WAPs in 2005. 2008 retains both options.
The File->New->Web site option is the only way to create a website application (or, at least it is in 2k8). The only way to create a WAP is to do File->New Project->Web->...
If you create a project, all cs files in your project will be compiled into one DLL. Instead, if you choose to create a website, all your app_code will be compiled and cached on the fly.
Related
We are interested in making some custom VS project templates for our developers and this would be a great help. More specifically, we want to create a unified starter VS project template for new SharePoint developers that could target both full trust solutions, CSOM/JSOM, and REST to build/deploy IA to both SharePoint and SharePoint Online. The idea is to add/manage common frameworks and utility classes for our newer developers so that we are always utilizing an updated managed VS project template, no matter what the project requirements dictate.
So is there any way we could use the VS designers for Content Types, Lists, and other SharePoint elements in non-standard SharePoint or SharePoint Apps VS project templates?
I'm developing a Visual Studio application with WPF, but right now is the moment where I have to choose my installer.
I need my project to be able to write on the GAC and on registry, but I'm not sure if I should use Visual Studio installer or Wix... I can't find on Google information that says exactly the differences between both of them.
I found that Wix is more complete, but I can't find any article that specifies real differences between one or another...
Can anyone help me to find more specific information or to choose between both of them?
EDIT: Sorry, I specify:
I'm using Visual Studio 2010 professional.
The end product is the same, a windows installer msi.
It's just different how you get there. With the old vdproj there wasn't much other than setting up files to be copied and registry keys as far as I remember. Anything else and you would have to create a custom action in C++ or VBS, not a particularly easy task if you are .net developer.
However with the advent of Wix there are a lot more in-built custom actions which enable you to create a rich installation experience and if you need to create your own custom action you can use .net. Also it is much easier to create a bootstrapper which can install dependencies along with your msi as well as being able to create a front-end in WPF.
As #nvoigt said the old vdproj type is not supported in VS2012 and it also cannot be built by a build server without doing some nasty setup (you have to install VS).
All in all there really should be no question of what to use, Wix is the way forward.
Caveman_Dick wrote:
"Anything else and you would have to create a custom action".
And that in a nutshell is the difference. Visual Studio Deployment Projects heavily abstracts you from the underlying windows installer and seals away a great deal of it's ability. This goes against the very design of Windows Installer which is supposed to be a declarative, transactional programming model.
Take installing a Windows Service as an example? Windows Installer has the ServiceInstall table. VDPROJ fails to expose this so you are off writing brittle custom actions resulting in a less elegant and less robust installer.
WiX on the other hand is a very thin abstraction. It's all about XML XSD elements and attributes that represent the underlying Windows Installer table data. The build process simply transforms the XML to SQL tables. If MSI can do it, WiX can (99%) do it.
VDPROJ was a horrible mistake and Microsoft has finally owned up to it and killed it. Now WiX doesn't have UI designers ( I've written one on CodePlex though) so you might also want to consider InstallShield Limited Edition (FREE).
Using a combination of ISLE and WiX I can get the best of both worlds.
With Setup projects no longer shipped with current versions of Visual Studio, you might want to use Wix. Otherwise, you will have to write it again once you switch to a current version of Visual Studio.
I recently upgraded from VS 2003 where I was working on a ASP.NET 2.0 website to VS 2010 where I have migrated to ASP.NET 4.0. So far it has been a big headache to get my site compiling with the new version. One problem was that my aspx.cs pages could not find the shared code libraries in my project. I solved this by moving my shared code to the App_Code folder (if there's a different/better way to do it please let me know).
Another issue that I am finding confusing is with pre-compilation. With VS 2003 I could click the build project button and it would precompile my site into a myweb.dll and myweb.pdb files. Now I'm having trouble doing the same in VS 2010. When I build the site in VS 2010 the dll is not created. I did manage to find an option to "Publish" the site which takes forever (like 2 minutes) and involves duplicating the site to another folder. This would have been acceptable but instead of making the single DLL file, it makes a bunch of files: App_code.compiled, app_code.dll, App_code.pdb, App_global.asax.compiled, App_global.asax.dll, App_global.asax.pdb, App_Web_lrpcway1.dll, App_Web_lrpcway1.compiled, App_Web_lrpcway1.pdb.
The application works - I can deploy it with all these files. However, I'd really like someone to explain what are the extra files and if there is a better way how to do it.
Thanks
This is the difference between a website and a web application.
You can convert your website to a web application to have it
behave more like you are used to.
The files in appCode are compiled when required to run and thus
does not provide dll.s in the bin/debug folder, but they should
be created when the application actually runs (but it is not
put in the same location).
Here is a nice write up about it Link
You can use the ASP.NET Merge Tool to combine all of the little DLLs into one big one.
http://msdn.microsoft.com/en-us/library/bb397866.aspx
Today I tried to use the publishing feature with visual studio, which creates an application manifest, and not a traditional exe.
What are the benefits of this?
I noticed each time the app starts up it does some kind of check before launching in?
When using Publish on a Windows application, you create a ClickOnce installer. You can find a lot of information about that in the official documentation. Basically, this is an alternative to creating a conventional MSI-based setup project (File/New/Project/Other Project Types/Setup and Deployment/Setup Project).
On MSDN you can find a comparison of the two approaches.
Almost all of our projects involve a web application or winforms application and a data access layer (class library) and stored procedures/database scripts.
We are looking for a good way to organize the solutions, and found a few ways:
1)We could have a sql server management studio solution for all the db related things, then have a visual studio solution for the application and data access layer projects.
2)We could do it all in visual studio with 3 projects, a sql server project, a web app/winforms app project, and a data access layer project.
3)We could do it all in visual studio with 2 projects, a web app/winforms app project and a data access layer project, and just put the sql scripts in a directory in the data access layer project.
I'm sure there's other ways, but I'm just curious to see how others go about doing it.
I have done this successfully using Visual Studio Team System Database Edition - multiple types dot net projects with a database project in a single solution.
Keep in mind that deploying a database project takes much longer because you usually need test data and most inserts thereto are RBAR insert statements. We used to turn off deploying the database project until absolutely necessary (usually once or twice a week).
Of course, all of this was in TFS for source code control
SQL Server Management Studio solution
allow use GUI designer for creating and editing some objects.
Visual Studio Projects
allows use TFS as version control and more integrate work of all developers working with a database;
better implements IntelliSence
I use Management Studio and some batch files to export/import/store the sql in the solution (under source control too).
So each time there's a change in the db it's exported to the solution and a custom tool is run to update the ORM proxy classes.