I have an Angular 1.4 application written using Typescript, making use of various typings e.g. angular-ui-bootstrap, angular-block-ui.
This application builds on my local machine.
However, when using a TFS build controller I receive numerous errors with messages along the lines of "Duplciate identifier 'angular'".
Now obviously each typings file will declare a namespace e.g. "angular.sanitize". The error will occur if the angular namespace has already been declared in another typings file.
I do not really understand why the errors do not occur on my development machine but do on the build server. I am using TFS 2010 for source control.
I have figured this out.
The build server had a different version of Typescript installed. Once I made this the same as my development machine all issues went away and my build worked.
Related
I upgraded my existing ASP.NET 5 project to ASP.NET 6, and now after I build it, I'm getting the following error :
My project was in ASP.NET 5 and now is ASP.NET 6 contains some razor pages alongside AngularJS typescript files.
The error was fixed after upgrading Visual Studio to v17.1.1
I have started maintaining a codebase that has not been built for several months. It uses Blazor. I updated everything to .net6.0 and I got the error described by the OP even though I am using VS version 17.3.6. I think in my case the cause is different and is due to using Blazor in a wasm project used as a shared library. This configuration is discussed here and here.
The solution I found was to exclude copy for the files causing the issue, by using DefaultItemExcludes in the project file as follows:
<PropertyGroup>
...
<DefaultItemExcludes>$(DefaultItemExcludes);wwwroot\mydir\*.*</DefaultItemExcludes>
<PropertyGroup>
I found the solution when preparing to create a new razor library as described here. I spent a considerable amount of time on this issue so I hope this solution and the associated links are of use to others.
Note that the solution means that the files are now not copied to the build project; however, this can be solved by either adding a post-build xcopy step or moving the assets to the application project and maintaining them there.
My solution is a net 5 solution. I've been through all of the nuget packages to make sure they are all 'net5' compatible and checked that all the .csproj target frameworks do indeed say net5.0 yet when I go to package my application (MyProj.Installer - Windows packaging application) it shows me a warning:
Warning NU1702 ProjectReference 'C:\Users\rich-\source\repos\MyProjGit\MyProj\MyProj.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. MyProj.Installer C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 1718
I have no idea where it is getting .NETFramework,Version=v4.5.1 from as the oldest version my project has ever been is 4.7.2 but more to the point it thinks it is a net6 application when it is a net5 application.
It goes through and packages the app as an msix file and I can install it after signing of course however the app fails to launch and I believe the reason is down to the warning I describe above. Am I missing any steps for packaging a net 5 application? I've taken the exact steps I have for a net framework application that have worked in the past.
So the app not loading was two fold. The app primarily didn't load as Entity Framework core 5 is referencing the wrong version of SQL Client. See https://github.com/dotnet/SqlClient/issues/652.
The second reason why the app wouldn't load was because the msix was trying to access a file I had open on another networked computer. See the section common problems https://learn.microsoft.com/en-us/windows/msix/packaging-tool/tool-known-issues.
Still no idea why the packaging project think it is net6 howwever.
Recently I've been running into an issue and I'm not sure how to best resolve it. We have a very modular architecture on the front end. We write individual angular components, put them in different repo's, and then include them in other apps as they are required, built with webpack & included via NPM.
Recently I've run into issues where multiple versions of a module end up in the compiled /dist folder coming from different places such as:
Directly included in the App I'm working on
2x Indirectly included through a module that I included (see chart for details).
The reason different versions could be used is that at the time CodeA is written ModuleA may be at version 1, then at a later date CodeB is written which also uses ModuleA which is now at version 2.
Then CodeA and CodeB are included in CodeC and now you have a module name collision on ModuleA.
With this setup, I believe if the multiple modules by the same name are loaded, the last one to get loaded is going to be the code behind that module name. Meaning it will be the one to be used by all modules. So there's no guarantee that the most up-to-date version is will be used. This usually results in getting an error that a method on ModuleA by name XXX does not exist.
To make sure I'm running the latest version of the module I have to go in and manually update (npm install) and build with webpack (npm run build) each library and then push them all to Github. Then I have to npm install in my root app. This isn't always an easy thing to do as the individual libraries' code may need updated to use the latest version of the module in question.
I'm looking for a solution to this issue. I'm guessing a structural/organizational change that will help us to not get into this predicament. If you have any solutions/advice/articles I need to check out please share. Thanks!
I´m pretty new to gradle and currently there is question that bugs me. The situation appears as follows: Based on a bower technology stack I implemented an Angular App. The app as it is doesn't change nor has it to be built in any way since there are just static javascript and HTML pages. In my opinion the used versions of angular, bootstrap and other libraries should also stay the same due to compatibility of the single libraries so these files also shouldn't change. Is this a correct behavior or should I get at least the latest build of the used libraries version as I deploy the application?
Also less is used in the application. Is there a way to compile the CSS every time I run the gradle build file or should I deliver just the compiled and finished CSS file?
As a result I´m also not quite sure if it's recommended at all using gradle to deploy an "static" angular application.
I hope someone out there can help me to answer the questions above. As you can guess, I´m not very experienced at deploying of such angular applications since this is my first project with this kind of problem.
This goes for all package managers, not just gradle but npm, gem, nuget, maven, whatever.
Use static dependancy version numbers. Otherwise you will end up finding breaking dependencies in QA or Prod rather than production.
This means you need to be aware of security fixes in your dependencies.
When you need a feature or fix in a new version of your dependencies, unlock the versions, rebuild and test in dev. Re-lock the dependencies and send to QA for verification.
I have a problem with Visual Studio 2013 generating too many errors when building a web application with typescript definition files. For example consider the following scenario:
Start a new Empty Web Application
Right click on project and select Manage Nuget Packages
Add jquery and jquery typings (the typings I downloaded are a couple of days old)
Build the project
Project builds successfully with more than 100 errors (errors, not warnings), all in jquery.d.ts, like the following:
',' expected.
'=' expected.
Identifier expected.
I get similar results when I do the same with angularjs instead of jquery.
Any ideas?
The most likely reason for this is that you are using an older version of TypeScript than the definition author.
The language is moving swiftly and some of the features in version 1.4 are particularly useful in definition files, so it is likely that you will need to upgrade to 1.4 so that your machine can understand these new features.
Download version 1.4 here.
I was having a similar issues like this but I was able to resolve the jQuery issues by downgrading my DefinitelyTyped version of "1.0.1" instead of "1.4.1". Also I'm currently running on Mac and hopefully this can help users who are experiencing issues on Mac.