In MVC 4, using the Bundles to define the files you want to include, you can use a {version} wildcard, for example...
"~/Scripts/jquery-{version}.js"
This works well when you have one version in the folder, e.g. jquery-1.7.js. However, when we have two versions in the folder jquery-1.7.js & jquery-1.9.js, it seems to pick up the old version, ignoring the new version.
Does the {version} wildcard find the first instance, and then move on? if so, the first instance in this example seems to the be the old version (as 1.7 comes before 1.9). So, is there a way of forcing it to look for the newest version if we have two files?
NOTE: The above version numbers may not be accurate, just used for scenario purpose.
In Mvc. It will load the old version first and then latest version. following will be sequence of jquery file load.
1.jquery-1.7.js
2.jquery-1.9.js
In this situation . latest file will overwrite the old version. so your page always get latest jquery functionality.
We ended up using something similar to this post, which tackles a similar issue. I will update the answer with a full description and code in the next few weeks once implemented fully.
Related
What is the simplest way to migrate a Grails app developed in 3.0.4 to 3.0.6?
The grails documentation recommends to create a new app and migrate every component one by one. But there should be a simple way if we are migrating within version 3?
Any help much appreciated
I run a grails create-app to create a fresh install of the new version. I then copy the files from the new version over top of my older v3 version. It's then pretty simple using version control tools to check for changes that need to be merged. The following files will have some changes that need to be merged into my existing project files:
build.gradle
gradle.properties
To be safe I usually also copy over the following, though they are less likely to have changes:
gradle/
gradlew
gradlew.bat
grails-app/conf/application.yml
grails-app/conf/logback.groovy
grails-app/i18n/messages.properties
grails-app/init//Application.groovy
With version control it usually takes less than a few minutes to review and merge back any changes that need to be retained. I find the process fairly simple.
I think you refer to this documentation https://grails.github.io/grails-doc/latest/guide/upgrading.html which is really about grails 2.x to 3.0.x migration.
In the case you're already on 3.0.4 you can just look at the release note of the version to see what is new and if there's any impact. As you will see its a lot of bug fixes and the introduction of the new web profile to create REST specific applications.
When you add a script bundle and have something like:
bundles.Add(new ScriptBundle("~/bundles/base.scripts").Include(
"~/Scripts/jquery-1*"));
It loads up the raw Jquery version and the minified version. Those files are both in the Scripts folder so I assume the asterisk is doing exactly what you tell it.
Is there a way to have only the minified version render when in debug=false mode and the raw version in debug=true?
Or is it down to actually specifying the exactly files you want instead of using the asterisk?
Regards,
Jacques
This should be happening automatically via the BundleCollection's FileExtensionReplacementList which should be selecting the .min version of the file when debug=false. The default templates when you create a new project should be using this functionality as well.
Although this question is now over a year old, in case someone stumbles across it in need of help on the same problem, Bundling introduces the {version} wildcard which uses a regular expression to look for a typical version number pattern (such as 1.9.1) so that when you update a package manually or via NuGet you don't have to go and change your Bundles configuration.
It will also be smart enough to select from files named .min.js and .js - using the former in release configurations and the latter in debug, exactly what the OP is after.
For ASP.NET MVC 4, this means with a debug configuration, the file
jquery-1.7.1.js will be added to the bundle. In a release
configuration, jquery-1.7.1.min.js will be added. The bundling
framework follows several common conventions such as:
Selecting “.min” file for release when “FileX.min.js” and “FileX.js” exist.
Selecting the non “.min” version for debug.
Ignoring “-vsdoc” files (such as jquery-1.7.1-vsdoc.js), which are used only by IntelliSense.
See Bundling and Minification and {version} wildcard in MVC4 Bundle
Word of warning though, if you have both jQuery-1.9.1.js and jQuery-1.10.2.js in the directory (for example) then both will be matched and added to the bundle - something that obviously is not desirable.
Note also that the minified version of the file must be named file.min.js, not file-min.js or min.file.js for this to work. The YepNope library for example is named yepnope.1.5.4-min.js when you get it via NuGet which means both this and the unminified version are added to the bundle.
when I run the application, the system crushes because of a bug related to
Problems with simple modal in IE9
The problem is that, even though there was an update on JQuery, the system continue to genrate a file jquery-1.3.2.min.js and I don't know where this comes from.
Tried the configuration files or on the internet. The file jquery-1.6.2 is also generated.
Any one can help ?
Its probably being brought over by NuGet during update or it may also be coming from source control. I wouldn't worry about it, just reference the jquery version you want and that should be enough for you assuming the file is in your solution and the link is right.
I have a Delphi XE project and I'm trying to change the version number of the program before building it with MSBuild. Version number information is located in the DPROJ file but if I change these values the version number does not change. I think the reason for this is that when you change version number in the IDE, Delphi saves the changes to both DPROJ and RES files.
Is there a way to compile the RES file from the command line with the changes in DPROJ file? I found this question which suggested saving the version number in an INC file and including that to the project but this feels a bit more complex solution compared to just making changes in DPROJ.
shameless plug: http://www.dummzeuch.de/delphi/dzprepbuild/englisch.html
I ended up solving my problem with this answer. First I unchecked "Include version information in project" in Project Options and added VersionInformation.rc with dummy data. When my build batch file is executed, it generates the correct RC file and because that RC file is added in to the Delphi project, MSBuild uses the contained information for built executable.
I use FinalBuilder to handle the version info. Isn't the stripped version bundled with your Delphi? If not, it is definitely worth the money. Makes releasing a one click action.
Yes you are right. Delphi keeps the version number in both project file and resource file. Unfortunately, resource files' structure is a bit complicated so it is not easy to update programmatically. When I came across this need, I ended up using a tool "SetVersion.exe" which did the job for me. It might help you as well. See this link.
EDIT
Actually now I remember, I used a different tool named "ChangeRes.exe" and it worked smoothly (but it is not free). You can try both and see which one works for you.
Some years ago, I have writed a script to build and increment build number using ruby and rake. Very easy to use.
After the build, the script calls Inno Setup and generates a new installer.
In the Delphi Project Properties dialog, there are settings for the "Product Version" and the "File Version". Can anyone explain the philosophical differences between the two?
The Product Version will be the version number of your whole application.
The File Version will be the version number of this component.
The two are usually in sync, but don't have to be. It would depend upon how modular your application was.
So for example you might have an application that's at version 2.3.4.0 (say), but one file reader component that's at version 5.6.7.0 as it was inherited from a different application and another at version 1.2.0.0 as it's a more recent addition.
Additionally, some components might not change between releases so theoretically they should remain at their original file version.
However, as this might well cause confusion (not least with the developer) about which file goes with which version of the product these numbers are often kept in sync.
Not all the files are to be changed when the product version changes.
E.g. you've written a dll implementing the core functionality that remains unchanged during following product version changes.
Product version is the version of the product the executable is a part of, like Firedox 3.5.2 - all files in the product should have the same version (for a given version, obviously). The file version is normally the version of the specific file, like the firefox executable, for example, without respect to the product. This doesn't seem to get used much.
In contrast to the file version the product version is not necessarily numerical. E.g. we use the pre-build scripts to set it to the current date. This way, we can easily check when an executable was built.