In the MiniProfiler.MVC3 NuGet package, it creates a file in App_Start that is used to control MiniProfiler settings (the SqlFormatter to use, modifications to the ViewEngines, when to start MiniProfiler, etc.).
There are a lot of TODO comments in this file talking about how to change the code to perform how you want. This is great, but when the NuGet package is updated, it will see that I've changed the file and not pull down the updated version. The problem here is that I lose any updates to that file, and depending on what else updated in the package, making it unusable (for example, when upgrading MiniProfiler.MVC3 from version 1.9 to version 2.0.1 after modifying MiniProfiler.cs in App_Start, the project will no longer build because of needed changes to that file in the 2.0.1 version).
What is the best way to handle this? Should I create my own file in App_Start and not modify the one in the NuGet package, ensuring that I will always get the full update when upgrading to the latest version of the NuGet package?
You could backup the file in App_Start, update it, then merge the files manually, or using a merge tool. You'd probably end up doing this anyways if you're using source control.
Quick-and-dirty: create the file you want. Then copy over/merge every time you upgrade with nugget. Or with every compile. The added build time is negligible.
Slightly better: use the precompile event in visual studio and compare the files. If they differ - either copy over or tell the user. I can't figure out a way to show a message box, or similar, on the top of my head but one could always create a new file with a compilation error and some text nearby "discrepancy in the xxx file".
try using mercurial queues. You can get your code to the point you want (excluding the file you refer to), and then commit. Make changes to your file, and push it to a queue. Make sure to exclude it from any future updates (manually), and then when you want to update your package, pop it off your code base. This will make it look like it used to, and run the nuget update. Then you can push the queue back to the code, and your changes will re-applied. It might take a bit of fiddling, but worth a look.
For reference:
https://www.mercurial-scm.org/wiki/MqExtension
https://www.mercurial-scm.org/wiki/MqTutorial
https://developer.mozilla.org/en/Mercurial_Queues
Related
Using ASP.NET Core 1.0, is it best practice to check in the project.lock.json file into source control?
Short answer: No, project.lock.file should not be checked into source control - you should configure the version control system to ignore it (i.e. add it to .gitignore if you're using git).
Long answer: The project.lock.json contains a snapshot of project's whole dependency tree - not just packages listed in "dependencies" sections, but also all resolved dependencies of those dependencies, and so on. But it is not like ruby's Gemfile.lock. Unlike Gemfile.lock, project.lock.json doesn't tell dotnet restore which exact versions of packages should be restored - it simply gets overwritten. As such, it should be treated like a cache file and never be checked into source control.
If you check it into version control, then most probably on other machine:
dotnet will think that all packages are restored, but in fact some packages might be missing and the build will fail, without hinting the developer to run dotnet restore
project.lock.json will be overwritten during dotnet restore and in most cases will be different than the version stored in source control. So it will be modified in almost every commit
project.lock.json will cause conflicts during merge
Actually you do want to commit your project.lock.json in git sometimes.
Checking your project json
For the exact reasons that, it shows you the dependencies you have used. Say:
Me as a developer works on an application, i hate every time updating packages so i add a package dependency to nuget package X = 1.*
I restore package i get version 1.2.4
The package maker just made a very stupid mistake, he broke something while just trying to make a fix and release 1.2.5
Person 2 checks out (or even worse release build kicks in).
Person 2 restores and gets version 1.2.5
Person 2 runs your application and find the application is broken.
Person 2 starts debugging and thinks there must be a bug in the software.
At this step 7 Person 2 could have seen in git that his lock file was changed and a newer version of a library has been downloaded, Which has not been tested by any of the other developers!
Downsides
Downsides of checking in this file is you might get allot of merge conflicts on continues updates of packages.
Alternative solution
Use only hard version dependencies (this is quite hard though for nuget). And only manually update to newer version once in a while.
Downsides
This doesn't work if you build a library for other people to use, since you pin them to a certain version of your dependencies.
Dependencies of dependencies still get resolved automatically so if you don't specify them yourself you can't guarantee there version on dotnet restore
Conclusion
If you want to avoid 'Works on my machine' quotes and the hell of constantly manually updating to newer version: Checking the project.lock.json.
And also build a CI/Release build check to test if this file wasn't changed compared to git, before you release (If your software is very critical)!
If this is not a problem and also automatically updating (to a potentially broken package) is not a big problem, you might not want to commit your project.lock.json.
No, it is just a lock file, really you should never check it in when a lock file exists (except if the program who locked it wants to check it into source control, in that case, exclude your lock file!).
I am developing a small meteor package, and I know that, to be consistent with the builds, meteor will create a .versions file in my package when I publish it.
That's fine, and I understand that, but, as the .versions should go in my version control (git) and I would like to commit the release before publishing it, is there a way to update the .versions package before publishing?
Also, the .versions file has a reference to the package itself. Is this necessary? If I'm developing version x.y.z of a package, why do I need to update both the package.js and the .versions file to reflect x.y.z?
Thanks,
Oliver
I don't think there's a need to add it to version control b/c I don't think the set of calculated versions means anything in a stand-alone package outside of the context of a meteor project. I'm not really sure what the file is used for at all since it doesn't show up in .meteor/packages when you install the package. It might just be nothing more than a by-product of running the solver.
So I never check .versions into version control and I haven't encountered any problems.
I'm using Perforce, if that changes the tune of the answers at all.
I'd like to implement a build process that, when a solution is built in a "release" mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it's ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I'm not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don';t have to worry about deleting out old files.
I'd say "Yes" - you should to start with a blank folder structure for your builds (regardless of source control system).
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.
I'm trying to make a setup program for an ASP.NET web site. I need to make sure the target machine has sqlxml installed.
I must verify the target machine has the software installed, and if not, launch a .msi file either before or after the main installation.
I'm a complete newbie with setup projects, so maybe this is obvious, but after several hours browsing the web I haven't found a satisfactory solution. I've been reading about WiX, etc. but I'm looking (if possible) for a simple solution.
Thank you both!
I understand an installer can't run another one. I was thinking in a functionality similar to Prerequisites (in project properties). There I can check a component and it will be automatically installed if it isn't. I don't need to do anything else. But, the most important thing for me is that the installation won't run if it's not needed.
I also tried the .msm solution, but I couldn't find any. Maybe I can make one myself? I haven't tried it yet though.
Unfortunately, you can't run one installer from another, since only one can be running at a time. You need to chain them together and run one after the other. Google "msi chaining". This is often the reason why products like Visual Studio use an external setup.exe which then runs the installers one after the other.
Looks like you need to 'chain' the installs http://objectmix.com/xml-soap/84668-installing-sqlxml-net-app.html
You can get the redist here http://www.microsoft.com/downloads/details.aspx?FamilyID=51D4A154-8E23-47D2-A033-764259CFB53B&displaylang=en
CAn you add this as a pre-req for your install?
What are you using to build the create the install?
Edit:
I had a look to see how you can check of the SQLXML is installed and come across this:
http://www.tech-archive.net/Archive/SQL-Server/microsoft.public.sqlserver.xml/2005-04/msg00110.html
The system I am on just now has the following key HKEY_CLASSES_ROOT \ SQLXMLX (note the X at the end), so you might need to do a bit more investigation in to what the actual key is.
I'm not familer with Visual Studio install authoring but if you can add an entry to the AppSearch and RegLocator tables you should be able to check for the existance of the registry key when the install starts. See here
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
The Reglocator table gives you the option to set a property with a value from the registry if found. You can then use this in the condition on a custom action.
A lot to put together, but I hope it move you in the right direction.
Brent's answer is correct. I would just add that, sometimes, you can find a "merge module" for the bits you depend on. That's a .msm file. You can certainly include 1 or more of those in your .msi file. I have no idea whether a merge module is available for SQLXML. Sorry.