I have ProjectA set up compiling and running in Visual Studio with Typescript. I now want to set up ProjectB, and use some of the code from ProjectA
So if my directory structure is:
c:\workspace\ProjectA\src
c:\workspace\ProjectB\src
c:\workspace\shared\src
is it possible to edit ProjectA and ProjectB .csproj files to point to the shared typescript code?
Thanks
I have tested this by placing the shared files (the TypeScript file and associated files) in a shared folder and then using Add > Existing Item and selecting Add As Link when I add the files.
If you are using reference comments, you'll need to use the relative path - if you drag the shared file onto a local TypeScript file it will generate this for you:
/// <reference path="../../Shared/Logger.ts" />
You will need to consider your deployment strategy. One way to do it would be to set the JavaScript files to copy on build, so they would all appear in your bin folder.
You might also want to consider packaging your shared stuff - you could make NuGet packages for them for example.
There is a workaround by editing the csproj file. You need to put in a entry for each subfolder, but for my case where I have lots of shared files, this is worthwhile. Using this method, all the files in a subfolder are also listed in the Solution Explorer.
<Content Include="..\..\shared\*">
<Link>src\shared\f</Link>
</Content>
<Content Include="..\..\shared\subfolderA\*">
<Link>src\shared\subfolderA\f</Link>
</Content>
<Content Include="..\..\shared\subfolderB\*">
<Link>src\shared\subfolderB\f</Link>
</Content>
The Link element shows the path as it will appear in the Solution Explorer. Note the extra \f at the end of the Link path. This can be any string and, for whatever reason, makes the parser interpret it in the way we want.
I've marked Steve Fenton's answer as correct since it is probably the best approach for most cases.
I was recently dealing with this problem. Here's how I got things running for me without dependencies on the other project.
I made my application with the source .ts files to run on my local IIS machine.
I then added reference to the js files in my testrunner file to point to the localhost address.
To write the tests and have access to the .ts files I just make added a copy as link file to my Typescript folder in my test runner project.
this worked pretty well for me. Thought I'd share.
By using Fenton's solution I was able not just to reuse source from project A, but also to debug it from project B. Solution behaves almost like project A is a class library.
Project A is a web app written in TS (empty web project template). Project B is UWP wrapper around Project A with some additional functionality. Here is the solution structure:
Solution
- Project A (ASP.Net Web Application)
- Scripts
- TS
- (all ts files)
- tsconfig.json
- App
- ts.js, ts.js.map, ts.d.ts (these three are result of compilation)
- Project B (UWP JS)
- Scripts
- App
- ts.js, ts.js.map, ts.d.ts (these three are added as links from A)
- TS
- (additional functionality)
Now, you can use breakpoints in Project A ts files while debugging Project B.
Related
So I am trying to connect up my Jasmine unit tests in a VS2015 web project with the resharper test runner and thought I would use the Auto-generate _references.js file to save me having to type the references in each test spec. The Auto-synced _references.js file doesn't however include any javascript dependencies from the wwwroot/lib folder. Bower is definitely copying them to that folder correctly, but the synchronization is ignoring that directory. I thought the references generation might scan the web project looking for .js files to reference but it seems to have missed a swathe of them.
According to Mads Kristensen:
Whenever a .js file is added, renamed, moved or deleted, the _references.js file is automatically updated to reflect the changes.
This doesn't seem to be happening with .js files in wwwroot/lib. Is this on purpose? Do I have to turn auto-sync off and do it manually?
How does Visual Studio process the App_Code folder when a change is made or detected in it? Not IIS or ASP.NET.
I want to gain a better understanding of why Visual Studio freezes for long periods of time whenever I save a code file inside a large App_Code folder of a website project. Alternatively, I could ask: why does Visual Studio not exhibit these same freezes when processing a file inside a class library that is equally large?
Ideally I would like to see official documentation cited from Microsoft of the issue at hand of processing the App_Code folder in Visual Studio and what happens that differs from processing a class library for example.
The App_Code folder is not explicitly marked as containing files
written in any one programming language. Instead, the ASP.NET infers
which compiler to invoke for the App_Code folder based on the files it
contains. If the App_Code folder contains .vb files, ASP.NET uses the
Visual Basic compiler; if it contains .cs files, ASP.NET uses the C#
compiler, and so on.
If the App_Code folder contains only files where the programming
language is ambiguous, such as a .wsdl file, ASP.NET uses the default
compiler for Web applications, as established in the compilation
element of the application Web.config file or the machine-level
Web.config file. Compilers are named build providers and a build
provider is specified for each file extension in an extension
element.
See the documentation here.
It recompiles all code in this folder in a separate assembly, then reference this assembly in your project.
You should be aware that a double reference could occur if you include these files as compilable in your project. In this latter case, the files are at the same time compiles in a separate assembly (with a temp name) which is referenced, and also compiled in the bin folder. This is the start of the horror show ...
These performance notes about the App_Code folder are slightly dated but likely still apply to the project type:
2) Keep the number of files in your /app_code directory small. If you
end up having a lot of class files within this directory, I'd
recommend you instead add a separate class library project to your VS
solution and move these classes within that instead since class
library projects compile faster than compiling classes in the
/app_code directory. This isn't usually an issue if you just have a
small number of files in /app_code, but if you have lots of
directories or dozens of files you will be able to get speed
improvements by moving these files into a separate class library
project and then reference that project from your web-site instead.
One other thing to be aware of is that whenever you switch from source
to design-view within the VS HTML designer, the designer causes the
/app_code directory to be compiled before the designer surface loads.
The reason for this is so that you can host controls defined within
/app_code in the designer. If you don't have an /app_code directory,
or only have a few files defined within it, the page designer will be
able to load much quicker (since it doesn't need to perform a big
compilation first).
-- http://weblogs.asp.net/scottgu/archive/2006/09/22/Tip_2F00_Trick_3A00_-Optimizing-ASP.NET-2.0-Web-Project-Build-Performance-with-VS-2005.aspx
I'm start to develop modules for DotNetNuke. I followed different tutorials(most by Chris Hammond) but there is something i don't like, and I'm searching a different way to do so.
He recommends to put a DotNetNuke installation, with IIS and SQL Server, on the developer PC and put your Project into the DesktopModules folder. I don't like it because i want to separate my project from DotNetNuke.
Is there a way to split the build/publish to different location like dll into folder x and all other stuff into folder y?
You could, but I don't really see the point. I see where you're coming from because it seemed awkward to me at first as well, but it really is the most efficient way to develop on the DNN platform. I have mine set up so all of my modules are in the same solution and branched in source from the root DNN folder. We don't keep the DNN core in source so the developer is responsible for that, although that may change at some point to keep versioning consistent.
By keeping your project located where it's installed, you can develop your modules the same way you'd develop any other web app you're building. If you make a change in markup you just have to save the file and refresh your page. If you change something in code just build and refresh.
If you really must keep them separate, you can absolutely do so (really the only benefit of this that I can see is that if you uninstall a module and accidentally click the checkbox to delete files - it happens - you don't have to worry about it). Create your project where you want it, change the Output Path to your DNN bin folder, and create post-build events to copy all of your .js, .ascx, and .css files (plus any others you may need - images, HTML files, XML files, etc.) to appropriate folder(s) in the DesktopModules folder. Just remember that you have to build the project every time you make ANY changes to test them, and you have to write/change your post-build events every time you add a new type of resource, change/add a directory, etc.
Either that or you can build an install package and uninstall/reinstall the module every time you change some padding in your stylesheet ... but I'd stick with keeping the project in the DesktopModules folder.
Sure you can do that.
Set up your solution and module projects anywhere, build the projects and copy the appropriate parts (such as the *.ascx , *.ascx.resx, *.dnn files) back to your website folder -
website/ DesktopModules/Your_module_name
Copy the module dll to the website's bin and you good to go.
I'm setting up an Orchard CMS project with the intention of creating a module to house my MVC 3 application. This application has already been started and has 5 projects already. One web project, some test projects and a workflow project.
Requiring that the web project (and therefore the other 4 projects for simplicity) lives within /Orchard.Web/Modules/ is a minor inconvenience - is it possible to change where Orchard looks (or add a new location) when dynamically loading the modules?
It's not a massive deal, but a nice to have for this project.
In an ideal world i'd be able to have:
/OrchardStuff/Orchard.Web
/OrchardStuff/etc
/MyStuff/MyProj.Web
/MyStuff/MyProj.Tests
I know i can arrange my sln in a nice usable way, would be nice if i could replicate this in the file system.
Cheers.
Wouldn't be easier to add an afterBuild task in your web project to copy the application to the Orchard's modules directory?
Something like that in the csproj file would do the trick (sort of, I am not entirely sure of my syntax. :'( )
<Target Name="AfterBuild">
<ItemGroup>
<AppFiles Include="**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(AppFiles)"
DestinationFiles="#(AppFiles->'..\OrchardStuff\Orchard.Web\Modules\MyModule\%(RecursiveDir)%(Filename)%(Extension)')" />
</Target>
The MSDN documentation is here: http://msdn.microsoft.com/en-us/library/3e54c37h.aspx
The solution I used is adding the following line to post-build operation:
if not exist "$(SolutionDir)..\Orchard\src\Orchard.Web\Modules\$(ProjectName)" mklink /D "$(SolutionDir)..\Orchard\src\Orchard.Web\Modules\$(ProjectName)" ""$(ProjectDir)"
This command creates a symlink of your dev folder inside Orchard's Modules folder (only if such symlink doesn't already exist).
It has the following advantages over #Eilistraee's answer:
If you change Javascript/CSS file in your dev machine, you don't need to build the project to get the changes into Orchard.
You don't get duplicate files on your drive
Post-build is a more explicit option and the macro variables make it easy to copy to any new module.
No that's not possible without some major efforts. Not worth it.
I have been working with setting up TeamCity, and I have almost everything working with the exception of being able to compile VS2005 solutions that have referenced assemblies that are outside of the solution path. I have our SVN repository structured as follows
Root
Libraries
Project 1
Trunk
Project 2
Trunk
Project 1 and Project 2 reference third party assemblies located in the Libraries. This works just fine from within the VS2005 IDE and when calling MSBuild on the solution files since the HintPath for all of the references look like this:
..\..\..\Libraries\ThirdParty.dll
The problem I have encountered is that when TeamCity dies the checkout from SVN for Project 1 or Project 2, it places everything into internal directories that don't match the structure of the relative path given by the HintPath.
How do I go about clearing this up, either through a TeamCity configuration or configuring my solutions/directory structure differently? Either one will work for my needs.
Thanks!
If you create a separate VCS root for Libraries, you can use checkout rules to control where the files are placed in the directory structure so that it matches the structure on your local machine.
We set up a network directory with all our third party dlls. Then we mapped the directory to a drive.
That way the dlls weren't a part of our solutions and all projects just call z:\3rdParty\example.dll to get the assemblies.
Someone else on my team actually set up our teamcity, so I could be completely mistaken about how the problem was actually fixed or if we even had that problem initially :)
What i have done is to set the VCS ROOT of the project to the top level directory ("Root" as per your project structure). And detached the default project vcs root created by teamcity. After this you can create a custom build step by specifying your solution here "Solution file path: *" in build type "Visual Studio (sln)". Now it properly handles library references.
There is a drawback here in that, since the vcs root is at the top level, even unrelated check ins could cause your project to build and that may not be suitable for time consuming builds. Don't have a workaround for that yet.