I have inherited a large LOB application that is built using TypeScript. The project has no reference paths in any of the files due to the fact it has been setup and created using Visual Studio 2013 - Visual Studio seems to have some magic where it will pick up the global TypeMaps itself. scoff.
The current build process has been to use Grunt to copy the compiled .js files (which are generated on save in Visual Studio) to a build directory - not actually compile them.
(to further reinforce this point, Grunt is NOT compiling any TypeScript).
This build process is now no longer acceptable as I am moving the application to a build through a Continuous Integration process, using Team City and Command Line tsc.exe/Grunt - so when the repository is checked out there are obviously no generated .js files in the project.
In its current state there is a host of compilation errors when trying to use Command Line tsc.exe/Grunt to compile the TypeScript files, I think due to the fact that the application is not using reference paths?
Does this mean I'm going to need to add all of the relevant reference paths to each file in the project?
Has anyone got any experience regarding this kind of setup and could point me in the right direction to manage these reference paths and build process?
Thanks
In its current state there is a host of compilation errors when trying to use Command Line tsc.exe/Grunt to compile the TypeScript files, I think due to the fact that the application is not using reference paths
No. You should use a tsconfig.json which will create the compilation context.
More
https://basarat.gitbooks.io/typescript/content/docs/project/project.html
A solution has been found.
Using the Visual Studio configuration options in the grunt-ts task I have setup the task to specifically use the projects .csprog and TypeScript 1.4 compiler (we are locked into this compiler).
My configuration for the grunt-ts task:
ts: {
default: {
vs: "Consortium.Client.Web.csproj",
options: {
compiler: "1.4/tsc"
}
}
}
I hope on the off chance, this helps someone else.
Related
So I'm trying to automate the process for building a packaged app from a Unity project and I've hit a roadblock when trying to use MSBuild to build the final app packages.
In Unity, when you build for UWP, a folder /UWP/ is generated for the project. These contain csharp projects for two .dlls that are required to build the uwp app.
For me, these dlls got generated in a folder for each platform (x86,x64, and ARM), but this is where I hit the roadblock. To build the app packages I use MSBuild(I've also tried with the Developer Command Prompt - same result) with the command.
MSBuild "{Project}.csproj" /p:Configuration=Debug;AppxBundle=Always;AppxBundlePlatforms="x64";OutputPath="AppxPackages"
This throws the error
"C:\Users\{User}\Desktop\Output\{Project}\{Project}.csproj" (default target) (1) ->
(BeforeResolveReferences target) ->
C:\Users\{User}\Desktop\Output\{Project}\{Project}.csproj(319,5): error MSB3030: Could not copy the file "{path-to-unity-project}\UWP\Assembly-CSharp\bin\AnyCPU\Debug\Unprocessed\Assembly-CSharp.dll" because it was not found.
What is happening here is that MSBuild is attempting to find a dll in a folder "AnyCPU" that simply does not exist.
Is there any way I could tell MSBuild to individually build each platform rather than look for a combined dll, or am I using MSBuild incorrectly?
Even though I was unable to figure out why the Debug configuration looks for an assembly in the wrong directory, thanks to #Leo-MSFT I was able to fix the error that was occurring.
Firstly, I was calling MSBuild on the game project, this needed to be the generated solution instead.
Secondly, instead of using the Debug configuration, I used the Release configuration.
And finally, I was confused by the contents generated by the build compared to a build from Visual Studio (Right Click->Store->Create App Packages...). While VS generates an .appxbundle, using MSBuild will generate individually for each of the platforms selected such as game_x64.appx, game_ARM.appx, and a few more.
You can create the bundle yourself by using the makeappx tool.
I'm having a hard time trying to build a F# project in Visual Studio that has dependencies downloaded with Paket. It raises several of the following errors (with different dlls each time):
Could not resolve this reference. Could not locate the assembly "XPlot.Plotly.dll". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. (Code=MSB3245)
For this very example, visual studio adds the option -r:C:\projects\StarWars-social-network-master\packages\XPlot.Plotly\lib\net45\XPlot.Plotly.dll. The file actually exists in my filesystem, so I don't know what I am doing wrong. Can anyone point me to a workaround?
Thank you.
From the directory name, I guess you're looking at Evelina Gabasova's Star Wars network analysis.
As far as I can tell, the project uses F# Script files and so you do not need to compile it at all. It is designed to be used with F# Interactive. Once you open the project, you can look at the individual script files *.fsx, select blocks of code and run them interactively - If you are using Visual Studio, this is done using Alt+Enter - other editors use either this or Ctrl+Enter (Xamarin Studio).
Many F# data analysis scripts follow this pattern - you're not really building a project that needs to be compiled and executed as a whole, so running bits of code from script files immediately makes a lot more sense in this context.
I'm working on a project that has a fairly standard Visual Studio 2013 build chain. One of the projects within the solution is used solely for compiling .hlsl files into .cso files, which are then loaded at runtime. When building from within the Visual Studio IDE, incremental builds behave as expected; if I edit color_ps.hlsl only that shader is compiled into its corresponding .cso file.
In the interest of expediting developer workflow, we have a system which automatically recompiles and then reloads shaders at runtime. Essentially, if the application is running and a user edits color_ps.hlsl, I launch MSBuild from the application to rebuild the project containing our shaders, and then reload its corresponding .cso file. Incremental builds here work as expected.
This all works fantastically, the only problem being that it seems that there seem to be some incompatibilities across the IDE and MSBuild. The first time compiling with MSBuild at runtime, all .hlsl files within the project are rebuilt. Further re-builds use incremental building as expected.
Furthermore, after exiting the application, attempting to build the shader project from within the Visual Studio IDE also triggers a full rebuild. Following re-builds use incremental building as expected.
My suspicion as to why this occurs is that the IDE and MSBuild do not recognize that their outputs are already up-to-date. To clarify, the output assemblies produced by compiling from the IDE and MSBuild are identical, and as such should be recognized as being up-to-date regardless of from where the build is being invoked.
Would anyone know a way to prevent these needless full-rebuilds when switching between building from the IDE versus invoking MSBuild at runtime? Thanks!
I am trying to clean and rebuild a solution file with multiple projects from the command line using MSBUILD. For some reason my build fails (about 10% of the built projects fail) and I get multiple errors which all look like:
error CS0234: The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)
Now if I clean and rebuild the same solution file from Visual Studio 2010 with the exact same configurations it will build successfully with no errors.
Is there a difference in the setup or configuration of MSBuild from Visual Studio that needs to be changed that I am not aware of?
I just had to deal with this issue and it turns out that msbuild likes to move built binaries into the binaries\release directory and reference those instead of the projects themselves when it builds things. After building it copies the files to this directory. This explains why it works in visual studio and not msbuild (I'm currently using TFS 1010).
In my case I had an old binary version of a dll being referenced by a project that was being built after the one that should have generated the correct file. The old one (binary) was overwriting the new one (built from source) as the solution referencing the binary one was being built later in the build.
I assume there's a difference in how the project is built, because Visual Studio does not run MSBuild, as it rather hosts the build engine itself.
This was answered here.
However, I've had similar problem.
In my case the project referenced an external library, which was placed in the project's child directory, unluckily named "packages".
After running MSBuild the folder's content was deleted, supposedly to be downloaded again by Nuget.
The obvious solution was to rename the folder and it worked.
Summary: Set Debug/Release mode in Visual Studio to the same settings as MSBuild to check for compilation errors.
I encountered the same problem:
Tried deleting all "bin" and "obj" folders.
Made sure all related projects are indeed being referenced and not just liked to compiled dlls. ex. Project B references A. Remove A from solution. Then add again. B would then reference A but via compiled dll only. Remove reference and re-add the project.
Finally switched to "Release" in Visual Studio. Turns out I had conditional compilation in some code (eg. #if DEBUG). So what was running in MSBuild and Visual Studio were actually different hence the error "The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)"
Try checking the paths to the references that MSBuild can't find in the non-building library's project file. Sometimes when you use VS or ReSharper to automatically add a reference for you the path ends up being to the \obj directory. VS seems able to cope with this, but MSBuild not so much.
For me the problem was that the some projects in the solution were not included in the build configuration for the solution. Those projects were dependencies for the projects in the build configuration, so all the projects in the solution failed.
After marking the dependcies projects with build in the solution configuration the msbuild ran successfully.
My issue was found in the solution file.
Remove all lines which reference 'ANY' for CPU and leave the 64 bit ones in.
In my case I had one PCL referencing another PCL with different targets. Visual Studio showed me a warning in the references list of the first library, but compiled the solution, whereas MSBUILD refused to compile. I fixed the problem by retargeting the PCL. Hope this helps somebody.
See my answer here.
Basically - Try running msbuild in a new cmd window everytime as a temporary workaround.
I was facing a similar issue. But after spending a lot of time, I finally came up with a solution (that performs similar to VS)
Use the following command to build your solution
"msbuild.exe project.sln /restore /t:Build /p:Configuration="Release";RunCodeAnalysis=False;RestorePackagesConfig=true”
I am trying to build a project from the following Source Code (it accompanies a book I am currently reading). Unfortunately, visual studio can not run a library with the name "cyclone_d.lib". I believe this is because visual studio simply can not locate the file. I have spent several hours trying to fix this problem by changing the settings in the linker and project, for example adding Additional Directories, but I have not been able to get any results.
Please let me know how I can fix this problem and compile the code.
Thank You!
Your link to source points only to some Unix-style source files but no VS project files. So I can only guess and give general help.
A VS solution contains one or more projects. Each project has a build target, in most cases a EXE, DLL, or static library LIB. When you have a solution that includes an project with an EXE build target set the option "Set as StartUp Project" at that project in the solution tree.
If you don't have an EXE change your project setup to create a Win32 executable instead a library. For this task the most simple approach is creating a new project (Win32 Console Application or Win32 Project) and add all the source files.