So I have this:
/projectA/index.html
And for the sake only for testing I want to have this in index.html
<script src="../projectB/somefile.foo"></script>
Of course, when I run visual studio, my foo file cannot be found because it is above the project "root".
Is there any way to allow IIS to gain access to projectB?
I am using TypeScript with Visual Studio 2013.
Note: I did google this, but I find asp stuff. As far as I am aware, this is not relevant to me?
Thanks!
The browser is trying to access the file at ../projectB/somefile.foo relative to where the current page is. Ask yourself this question, if you were using a web browser, how would you navigate to ../projectB/somefile.foo?
I'm going to make a bit of an assumption and guess that index.html is at a url that looks something like this:
http://localhost:55685/index.html
Now, as you pointed out, it doesn't really make sense to go up a directory using ../ when you are already in the root directory.
You have two options I can think of right now. One is that in the project's properties, on the Web tab you can configure a Project Url for projectB. For example http://localhost:55685/projectB. Then in your app do this:
<script src="http://localhost:55685/projectB/somefile.foo"></script>
You'll have to do some additional configuration if you ever deploy your application, but it's a solution that works if you just need it for development.
Another option is to copy the script files from projectB into projectA. I would recommend this, especially if projectB isn't going to be deployed somewhere. If you are trying to access some TypeScript files, you can use a method similar to what is outlined in this other answer. Otherwise, just make a build event that runs a script to copy all your script files into projectA. After that, reference the script files you need at the location you copied them to in projectA.
Related
I'm having several projects containing my javascript sources and one project containing my javascript tests. Now I'm wondering how to set my references in the test files to make them work in Visual Studio and the automated integration build on server side. The challenge is that the file struture differs in both locations.
Locally (Visual Studio) there is the usual file structure:
project-a/
content/scripts/library-x.js
tests-project/
tests/library-x-test.js
I set a reference in library-test-js which looks like this and works fine in VS:
/// <reference path="../../project-a/content/scripts/library-x.js" />
On server side everything is copied to the build output folder what changes the file structure to look like this:
build-folder/library-x-test.js
build-folder/content/scripts/library-x.js
The reference in library-x-test.js doesn't work anymore there. Any ideas how to solve this issue?
You should use the chutzpah.json file to configure your file paths instead of the reference comments. The chutzpah.json file give you more control and lets you use wild cards. Path's in the chutzpah.json file are relative to the location of that file so you are sometimes able to make things work in both build and local as long as you place that file correctly.
The project I'm currently working on uses Nant build scripts for the continuous integration server builds. The build file is stored in a folder in the repository.
I find it annoying having to browse to it via windows explorer rather than it being available from the visual studio solution when I need to make changes.
I was wondering if there is any reason not to include it somewhere in the solution for ease of access? If this isn't daft where would you store it in the solution? Would you create a dummy non building project for holding these type of resources?
Thanks,
Neil
Go right ahead and add it to your solution file.
You will either get, or have to create manually, a folder for it, but I think that when you add it you will get a folder called Solution Items.
As far as I have seen, there is no real reason to not have them along with your project solution. In one project, since there were lots of build files, it made sense to create a separate solution for them.
We are trying to adapt a build automation strategy for our ASP.NET web site (not a web project) in vs 2010 ultimate & tfs 2010.
Build definition makes the build and publishes the web site into folders like
<drop_folder>\<defn_name>\<defn_name>_<year><month><day>.<build no>\Release_PublishedWebsites
Now we try to delete particular files and folders from that folder. For instance the "images" or "files" folders, that we need to exclude before packaging. I know that if it were a web project, there exists a straightforward solution. We also tried to modify the build process template (xaml) file. There is a "DeleteDirectory" component but we couldn't figure out what to write to the Directory variable.
Thank you.
If you follow the XAML way, you would just have to feed the Directory argument of DeleteDirectory with the physical UNC path to the folder you 're trying to get rid of.Something along the lines of String.Format("{0}\\{1}\\{2}\\Release_PublishedWebsites", BuildDetail.DropLocation, BuildDetail.BuildNumber, Date.Now.Year)
should get you near to your target. Since the drop location of the build might be on a different machine, also ensure that the account conducting the build (by default = NetworkService) has the rights to delete folders on the target.
In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?
I am writing a small application at the moment and am trying to organise my build output to be a little closer to the finished product. The application is made up of a number of different projects. There is a core library that contains most of the functionality, a GUI app and a command line app that both reference the Core Dll, and a number of Plugin Dlls that are loaded at runtime and implement different data sources, these all reference core.dll, these also may include some other third party dlls. There are also a number of peripheral files such as a readme. And finally the core.dll and the datasource plugins are unit tested.
I would like to configure my build so that everything is output into directories as I would expect it to be when installed. I want debug and release builds to be built into different directories but otherwise have the same directory structure. I only want tests to be built for debug builds, and want them to be runnable, but seperated (I guess all test dlls would get output into a seperate directory). Here is how I imagine the structure will be.
Code/
solutions etc here
Debug/
Project.Core.dll
Project.Gui.exe
Project.Cli.exe
readme.txt
lib/
ThirdParty1.dll
ThirdParty2.dll
DataSource/
DataSource1.dll
DataSource2.dll
Tests/
Project.Core.Tests.dll
DataSource1.Tests.dll
Release/
same as Debug but without tests.
Is there any way of getting a solution to build like this? I'm beginning to think it will be difficult to build the plugins and the app all from one solution, and probably not even wise, but as they will all be distributed together it would be nice. I am open to using Nant or another build tool if that will make it simpler.
It is possible. Just modify OutputPath tag manually in each .csproj in both Debug and Release file to something like this
<OutputPath>..\$(Configuration)\any_subdirs</OutputPath>
You can disable tests building for Release using Configuration manager.
Modifying each project every time you create a new one is annoying.
Here's the solution:
Locate the real vs project, it'll be somewhere under ("%programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates*")
Copy it locally somewhere.
Extract it.
Edit the contents making changes that better suit your project layout style. Make sure you update the project name, the name is what you see when looking for the project in the new project dialogue box. It's xml tag is Name, you'll find it in the {something}.vstemplate file.
Compress the content again. (Note: the contents must NOT be in a sub folder, so /* and NOT /{somefolder}/*).
Place your custom project under ("%USERPROFILE%\Documents\Visual Studio 2010\Templates\ProjectTemplates*").
Add a new project is Visual Studio, selecting your custom one, and enjoy!