A developer created a web front-end and deployed on server. Unfortunately when the vue application was developed I did not receive the original vue files so all I have access to are the files deployed on the server.
I'm unsure how vue works and if deployment means that the web application is compiled. If this is the case, is it essential to have the original vue project to make changes ?
What disadvantages will I encounter without the project file?
Thanks
If the original developer used VueJS-cli to develop, you should have the source code at src folder.
The deployed assets are generated in a build phase, and keep apart from source code.
The deployed code is in folder dist in server.
If you only received the dist folder (the compiled assets), maybe it is a difficult to reverse engineer the code, because you only have the minified and uglified version of the source code.
Related
I want to start playing with Aurelia and MVC 6 Web API with Visual Studio 2015 RC, and I'm using OdeToCode's blog post as a starting point.
I understand the idea behind the new wwwroot folder, but I'm basically confused as to what should or shouldn't put in there.
My initial thought would to install all jspm packages as well as the actual JavaScript source files outside the wwwroot folder, and then copy with gulp everything that's necessary for running while developing or bundle and copy when deploying.
It would look something like this:
But then again, should I place index.html also in the src folder? and config.js? Or am I actually making my life difficult for myself and should just develop from within the wwwroot folder?
It's the jspm packages that confuse me; it feels wrong to have such a large amount of JavaScript files in the wwwroot when I plan on bundling and minifying anyway.
In short: What would be the preferred folder structure for an Aurelia ASP.NET 5 app in Visual Studio 2015?
I spent quite some time on this and finally settled on:
ApplicationName
src
Api
In here I have an ASP.NET 5 project that provides the api to be consumed by the Aurelia app. You will likely need to turn on CORS to avoid errors.
Client.Web
In here I started with the Aurelia skeleton navigation app. We changed the dist folder to wwwroot. The jspm_packages folder sits outside the wwwroot and the gulp tasks that come with the skeleton navigation app take care of all the copying to wwwroot as needed.
This approch gave me the following benefits:
Clean separation of the api and the client code.
Option to deploy the api and client separately.
Ability to leverage all of the gulp tasks that come with the skeleton navigation app
Clear place to switch over to the Javascript file naming conventions (camelCase)
The drawbacks of this approach:
Starting the full app is more difficult. Currently, I have to click "Play" in Visual Studio to start the api, then I have to start gulp watch. This is not too big of a deal because you can mostly leave gulp watch running the entire time you develop.
My company uses TFS 2010 to deploy our web apps from our local environment to our development environment. Here's the compiled output in my local directory for one of our vended web apps, ProGet, (http://inedo.com/proget/overview) in question that isn't deploying correctly. I expect all of what I see below to deploy to our development server:
Here's my .xaml build file:
Finally, here's my solution in Visual Studio:
When I queue the build, this is what's built out to our development server - notice it's missing a bunch of files/folders, but it does include "Resources" and "bin" and web.config:
This app is a vended application, ProGet, an already developed corporate Nuget repository that we purchased a source code license for. Does anyone have any ideas what I might be doing wrong?
EDIT
Here's a screenshot of my local IIS and the window to the right is a result of right clicking the website and choosing "Explore". Notice the *.cs files. Weird they don't compile down.
The Default Build Template (DefaultTemplate.xaml) should output the same files you get when you compile locally.
However, from your screenshots it looks like you are using a custom build template xxxx_DeploymentProcess.xaml that is obviously doing something different with how it outputs the build files. There is no way for us (stackoverflow community) to know what your custom build process is doing.
You could try switching back to the default template, and we'd be able to help you then. But, there's a good chance that you are using a custom build template for a reason, and you might not want to eliminate it before you know what it's doing.
I am working on an asp.net mvc web application. I have prepared a web deployment package from my staging environment as a zip file, then I publish this web deployment package inside IIS on production server and it worked well.
But currently I need to modify a Controller class to fix a bug on production. But I am not sure how I can publish this specific controller file to my production server .I test the fix on staging and i need to deploy on this controller class to my production server. can anyone advice?
Thanks
You need to deploy built *.dll assembly file rather than source class file. It should be within \bin folder.
Usually it's called as [your-project-name].dll.
I have various IIS hosted service hosts with simple svc files etc. What I want to do is to be able to create deployment packages from our test server using IIS Export Package in a way that parameters may be saved and picked up at Export time so that the Export is repeatable and automatable. I.e. the Export will always use the necessary Manifest extensions such as XmlFile etc.
The web sites exist in the solutions and are then picked up using a Web Deployment project in each solution so that config substitutions are done etc.
We are currently on VS 2008 SP1 so do not have direct access to VS 2010
The first issue I have with MsBuild (running in TeamCity) is how to build the IIS web site (with target=Package) when there is no project file? In this way maybe I can avoid the Web Deployment projects (I use them for various configurations but don't want to do it this way for deploying to Production but rather export from our fully tested staging into a package file to be imported onto a production server).
Secondly, I want to avoid having to configure the Export in IIS 7 each time I run it. I want it simply to pick up the correct set of extensions to use and create the necessary parameters for me. Is this done from a Manifest file? I can see how to use the parameters.xml but I am unclear whether I need to use a manifest.xml (created by hand) and how to link it in. The idea is that a tester/deployment person should be able to do the Export simply without having to enable all of the extensions that are required
Any help or guidance will be greatly appreciated.
Ok, in the meantime I got it figured out.
I ended up using the document at Package an Application for the Windows Web Application Gallery which gave me the means by which I could extend our automated build in TeamCity to create the "repeatable" export packages.
In short I will use the current Web Deployment Projects to create the deployment artefacts and then in MsBuild combine them with the pre-prepared manifest.xml and parameters.xml files into Build artefacts folder and zip them up into a package. From there the task will be to Import the package into IIS Deploy in the target environment.
The parameters.xml file will be used to set the HostName for wcf clients and services, connection strings, app settings etc.
This turned out to be the best solutuion bcause I can put it into our automated build.
I am pretty new to msbuild and aspnet_compiler.
I am using aspnet_compiler to compile web application project. Now I just saw the MSBuild.exe and noticed that its builds my website into the /mywebsite/precompiledWeb folder. Now why do I need to use MSBuild.exe? Can't I directly use the aspnet_compiler to see if my website can be built properly?
(Not sure if I explained it very well).
msbuild.exe is usually used to build projects and its dependencies. When you have a web application project with a project file, vs can use this to build not only your web project but all the dependencies involved. This would only build your source code files, not the markup files (.aspx,.ascx,.etc).
aspnet_compiler is meant to build a web site project that doesn't have a project file. This said, you can also use it to make sure your markup files are also built for your web application project.
You are correct you can manually invoke the aspnet_compiler.exe tool. But better would be to use Web Deployment Projects to help you do this.