I am trying to find out what is the alternative to using the Web Deployment projects in VS2011 as they do not seem to be supported anymore.
We have a number of projects where we are using them to share .ascx components among different projects.
What is the recommended way to do that now?
We have not yet finalized our plans for Web Deployment Projects for VS 11. We will be working on finalizing those plans in the coming week. If you have a specific scenario that you are trying to unblock I can try and help you. Feel free to send me an email at sayedha {at}[microsoft{dotcom}.
We are using pretty straight-up MsBuild to do stuff. The secret is a hidden target called _CopyWebApplication -- that actually copies the built web application and such to a folder.
I have no idea why something this useful is hidden and undocumented.
Related
Has there ever been a more confusing/difficult time to be a web developer using the Microsoft stack? That's not really my question... I know that the answer is a categorical no. :)
The single page app template that comes with VS 2013 is deplorable.
I've been working on building up a similar project template that uses Angular JS on the client, but I'm starting to spin my wheels a bit porting over the external (openId/oauth) login features.
I believe this is because of the lack of good, single-point-of-truth, and current documentation for Katana's auth/security bits and also because of how unreadable the client side code is in the S.P.A. template in visual studio 2013.
I know that I can get through it, but while I'm struggling with it, I'm wondering:
Are there any good community provided project templates or example code bases in existence that use .NET 4.5 (MVC5/Web Api 2), Angular JS, the new ASP.NET Identity stuff, and the Katana packages?
There's HotTowel.Angular, but it takes no stance on security. Besides, it's a Nuget package, which can't or shouldn't dictate as much as a proper project template can.
I agree with your observations. I have found the following setup that seems to meet your requirements and I think works very well (I don't have a template), I would suggest the following:
Create an empty WebApi2 project and adopt authentication/authorization depicted here
Use a regular index.html in the base directory as a launching point for your angular application. You can either maintain your client packages with nuget, npm, or bower.
Use whatever technique you like for organization of client code.
Personally, I would create 3 projects, One for client code, (mydomain.com) One for your api (api.mydomain.com) and one for your Model/Repository/Data Access layer.
update
Here is an open-source project that might be what you're looking for!
When developing for Alfresco, are there any advantages to using the MMT over Integrated Deployment? Is there anything you can develop using one method, but not the other?
Browsing through Alfresco's SDK examples, I noticed many of them used integrated deployment, and the same went for all of the Share webscripts I saw on Google Code. Right now I'm just using the Integrated Deployment method, and everything seems to be working well, but I'm curious if I'm missing out on anything by not using the MMT.
Modules and integrated deployments are exactly the same in terms of code capabilities. The main difference is about distributing your customization: if you need/want to
provide your customizations to the external world or
reusing them across different projects or
port them to different Alfresco versions
then modules are the way to go, especially if you're not releasing the source code. The only downside of AMPs is that they write something in the DB but you currently can't uninstall them, even if there are some tricks you can try out.
I personally still prefer using AMPs as much as I can for my customization, leaving to embedded changes only stuff that can't go into an AMP (e.g. overriding original Alfresco files). The maven way also helps (and drives you a little) towards this practice.
I have been looking for a solution for breaking up a large enterprise web application into smaller more-manageable modules and be able to build and deploy individual sub projects while at the same time have each sub-project inherit from a common set of resources such as master page, parent Page class, app_code, css, etc.
I found a workaround for setting this up in VS 2005/2008. in a Visual Web Developer Team Blog Post .
Question is: Is there a new approach to solving to this problem in VS 2010 (apparently the same workaround mentioned above doesn't work for VS2010). Or perhaps I'm going down the wrong road altogether; although it makes sense to me that this would be the desired way to setup large enterprise applications, if not whats the industry standard or best practice?
Your help and comments are appreciated.
Thanks.
Break your solution in an organized manner identifying major blocks and separating thins the way that best fit your needs.
A good example to get started is nopCommerce that can be found at codeplex. An older version (web forms) is also available.
We have been a ColdFusion shop for 10 years, and are now switching over to ASP.net MVC. Our target framework is .net 4.0 BETA 2 using VS 2010 BETA 2. We set up two instances of Windows Server 2008 (staging and production), and will be using our existing database server (SQL Server 2008).
None of us really have much experience in ASP.net itself, though we are all very comfortable in C# and the MVC pattern. The coding itself isn't much of an issue; but the deployment process is. Our goal is to be able to have a CI setup that will automatically pull down, and test, our applications into staging on commit - then have the option to tag, then switch, the checkouts on our production sites when websites pass QA.
Some of the things I'm having issues with here is the concept of an ASP.net application and how it integrates into SVN. CF, like PHP or RoR, are all scripting languages and as such require no build process (checking out the source into production is very straightforward). But in this case, applications need to be compiled - which is where we start to have problems. Will we need to create another server (or use an existing one) that has some sort of application that pulls down code, compiles it, then somehow pushes it on the live servers? If so, what is considered the best way to accomplish this? I imagine if we end up using a build tool such as Nant, adding additional steps to migrate the database would be trivial, but what is the best way to accomplish this as well?
Another, slightly unrelated, problem is how our designers will work with our code. Most of them are on Macs, and using VS isn't much of an option. How will they be able to edit the aspx, css and image files easily? Our goal is to make this as transparent as possible to them.
We have done a lot of shopping around, and ASP.net MVC seems to be the best option as far as our familiarity with the language, and our current platform. We just need to figure out a good build process so everything is as transparent as possible. I understand there are a ton of resources available on this, but I wanted to get the opinions of the people here from first-hand experience.
Microsoft TFS has a wonderful build solution built-in. It's costly, but effective. In addition, you cannot lose by looking at CruiseControl, which is free. TeamCity from JetBrains is also a great option. All of these Continuous Build and Integration solutions would provide a good starting point for your research.
http://msdn.microsoft.com/en-us/teamsystem/dd408382.aspx
http://www.cruisecontrol.com/
http://www.jetbrains.com/teamcity/
Even Draco.net is a good consideration:
http://draconet.sourceforge.net/
We use http://www.cruisecontrol.com/ (CC) running on our SVN / Build server. You can configure CC via it's own config/script files to pull down the latest source from SVN and then spawn one or more Nant or MSBuild scripts which can perform your build and deployment.
We script all of our database changes into change scripts which also go into SVN. We then have a custom command line tool which will deploy the change scripts to SQL Server during the web site deployment. All of that is done in the Nant script.
So each project's Nant script handles the build, web site deployment and SQL change script deployment.
The tricky part is handling rollbacks if/when something goes horribly wrong. I would suggest posting another question for that specific problem.
What is the simplest way to distribute an asp.net web application? I tried to look at some of the open source asp.net projects out there to see how they distribute their apps and how they do updates and they seem rather complicated to me (not for myself to perform but for non-technical users). A lot of them entail backing up the entire installed project, deleting specific folders and save parts of their web.config. I am hoping to find a solution that will make the update process specifically as simple as possible.
Thanks.
I am working on a project with a similar requirement now. We decided to use WiX to create an installer that can be run on the server or machine where the site is installed. WiX is incredibly powerful, but takes a bit to get the hang of.
There are plenty of other open source, and paid installer technologies as well. Here is a post with some info on a few.
CommunityServer provides a setup msi that will create a virutal directory, generate the SQL database and populate it with default data. Updating for point releases though is still a manual process involving an update.sql file and having everyone download then merge binary and static file changes.
They probably could have created an update msi too, but because so many people customize CommunityServer, it is probably better to let people merge changes themselves.
Do you mean in terms of breaking up the functionality into tiers that could be handled on separate machines, e.g. having 3 servers for a 3-tier architecture where one is the DB server, one handles middleware and the other handles the requests in ASP.Net? Another point here would be in going from a web server to multiple web servers in terms of scaling up.
Or are you referring to deployment?
It's a web application, man. Serve it publicly, require registration, and move on. Isn't that the point of the web application?