There are a few packages that I install 95% of the time I write any scripts in Linqpad. For instance, JSON.net, is a nuget package I install every single time, and RestSharp is a close second. So my question is, is there a way to set up Linqpad to install these nuget packages by default? If not, is there a way to add them to a collection so that they can easily be installed every time?
There are two ways:
Add these packages to the My Extensions query (then they'll be implicitly referenced by all queries)
Add these packages to any query, and press Set as default for new queries
Yet another option is via a code snippet. Right-click the editor and choose Create Code Snippet, then click the References checkbox to add the NuGet package. Whatever you name the snippet becomes a shortcut to add the package, so if you name the snippet json, you just type json followed by the tab key, and it will add the package.
Related
I have a folder in TFS which has SQL Scripts. At the moment I am manually adding a comment and updating a version number inside the comment every time i make a change and check it back it. This works however was hoping there might be a better way. Is there a way to automate this in TFS?
I have read the following article
Version control project files
do i have to go through such a process for simple .sql files? Are there any other simple ways.
There are a few ways you can do this:
Create an automated build in TFS and write a custom build step / PowerShell script to parse the appropriate SQL scripts, read the version, increment it, and store the new version by either checking in the updated file or a local store
Use a database project (part of SQL Server Data Tools) which will output a DACPAC. Inside the database project, you can set the version as specified here. This stores the version in the project file. If you update your TFS build number to be digits only, you can then update the project file to set that value to match the build using a custom build task. For example, if your build number was yyyy.m.d.R where R is the number of times that build was run today (TFS manages that - it's the revision variable). Or, you could set the the <DacVersion> tag to something like 2.1.0.0 and your build replaces the last digit with yyyymmddr.
I'd recommend using a database project. It's pretty easy to create a new database project off an existing database.
The first way mentioned by Jacob above can achieve that if you just want to incremental the version number of the script/folder, just create a CI build definition.
Actually you can just enable Label sources and set the Label format with predefined environment variables such as $(build.buildNumber), and set without publish any artifacts during build process.
Thus, it will automatically trigger the CI build when you check in files, and the source (SQL Script /folder) will be labeled with the incremental number.
Then you can find the specific versions with the label.
I have the following variables defined:
Now once a build is complete (the last step in the build process), I want to update the VersionRevision variable, basically increment it.
So I'm looking for an API I can call from C# and create a console application or a powershell script to edit the build definition (if I have to do this)?
You can use VSTS Rest API to update the variable value in Build Definition. Both Console Application and Powershell Script is OK for this.
If I understand correctly, you want to get these build variables and them assignment them as your version number.
After the build completes, update and increment the VersionRevision. It's not a good way and seems not available to achieve it.
In TFS build there is a $(Rev:.r) which means
Use $(Rev:.rr) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
Source: Specify general build definition settings
To version your assemblies you could just add an powershell script in your build definition, detail ways to achieve please follow this link from MSDN: Version your assemblies
And usually we only define and assignment variables with the Major and Minor version. If you want to change the value of them. You may need manually edit the build definition.
More related link about how to manage version numbers as part of your vNext builds.
vNext Build Awesomeness – Managing Version Numbers
Generate custom build numbers in TFS Build vNext
I have some SSIS packages that connect to an Oracle database. The connection parameters are stored in a SQL database and retrieved by using the Package Configuration tool.
My problem is that the variable that gets populated automatically by SSIS with the configuration string does not get emptied after the package is run. As a result, the value of the variable get saved in the source code when the package is saved. I DO NOT want to have this variable value saved in my source files.
Any idea on how to prevent this from happening?
Thanks!
You can try setting the variable in a package configuration. The way you do this is simple.
First go to the top most layer of your package and right click on the empty space and select package configurations. Choose to add add. Give a location and name for the file and then click next.
Once you've done that choose the variable you want and set the value like this.
Now you're not storing the actual value in the package. Just the information for how to find it.
EDIT: I may not have been clear on this. This process will create a completely separate file that the package will look to to get that expression. This way you don't have to store the expression or the value in the package itself. It just knows at run time to go look for that config file for any additional data.
EDIT 2: The package configuration will only overwrite when you execute the package in BIDS over Visual Studio. The reason this happens is because the package evaluates and then saves prior to run time. This does not happen when you are using SQL agent to run a package and therefore will not store the value or the expression in the source code. I hope I have clarified that for you.
I have created a package with a bunch of assemblies that we will provide to our users. I want our users to be able to pick and add only references they need from within the package to a project. The user should be able to add this package at a solution level and then pick the references to be added to each project from the package added. Is this possible with NuGet?
Example:
MyPackage - contain foo.dll, bar.dll, bla.dll
User installs package "MyPackage" to solution
Project 1 - select and add reference foo.dll, bar.dll
Project 2 - select and add reference bla.dll
Currently, every reference of the package is added to every project. This is not the desired setup. I want only the selected references added. Is there a way to do this with Nuget?
NuGet is not designed to work this way. Packages are whole delivery units. Our recommendation in this scenario would be to package the individual assemblies according to how you want them individually installable.
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions