My sincerest apologies, if this has been asked before. I've searched the site but have not seen an answer for what I'm looking for yet.
For years, my company has referenced custom binaries in a local folder hierarchy within source control. We're in the process of changing our source control, and in the process are defining new strategies for many things. One of the things I've been working on is to setup a local NuGet feed for our custom packages to replace the old source control folder method. I've been able to successfully create custom packages and using the package restore feature, log into our build box to restore both NuGet packages from our local feed, as well as those from the official NuGet feed. Everything has worked well up to this point.
The time has come to begin testing our migration process from our old source control to the new source control, and convert all of the references over to NuGet packages. Where needed, we're creating packages and placing them on our local NuGet server. The issue I came across today involves a project that uses an old version of a vendor library. I searched the official NuGet feed and found the library as a package, but the particular version we used at the time is no longer available.
I know from the fact that package restoration was a highly requested feature, that other companies are already employing the strategy we're attempting now. My question is what strategy is your company implementing when operating under this criteria? Is there a best practice we should be considering?
Thanks for your time and assistance.
That's quite a big question to answer so I'll recommend you some resources to read up on this topic.
I wrote an MSDN article on some patterns and practices I'd recommend when using NuGet into the organization. Maybe you'll find something useful in there: http://msdn.microsoft.com/en-us/magazine/jj851071.aspx.
There's also the book Pro NuGet available at http://bit.ly/ProNuGet.
Related
I have built one windows forms application and I published for client installation. While installing the setup file, it should ask the user to select the installation directory path; instead, it's installing in default path as below :
C:\Users\Mysys_t\AppData\Local\Apps\2.0\434YBBVC.Z2H\TNYPR09N.1JZ
Is there any settings to do this, so that, while installing, user is able to select the installation directory?
In general, the answer is no. See a related MSDN forums discussion among other online references that explains why: ClickOnce was designed to automatically manage installation directories to prevent deployment collisions.
Now...the referenced MSDN forums discussion also links to one way to possibly work around this. Certainly anything is possible with some ingenuity and work (e.g. publishing a setup wrapper with ClickOnce to leverage ClickOnce's auto updates but use indirection to control where your actual app ultimately gets installed); but this is not possible using ClickOnce "straightforwardly".
this can be achieved by
Creating an MSI Package for C# Windows Application Using a Visual Studio Setup Project
pls follow the link below :
http://www.c-sharpcorner.com/UploadFile/1492b1/creating-an-msi-package-for-C-Sharp-windows-application-using-a-v/
I have just started using SSDT. Is there any way I can get a graphical view of my database and the relations between the tables?
Thanks!
Currently, no there isn't, nor is there any 3rd party plugin for it either (as far as I have been able to establish).
There was some talk a while ago about it possible coming, though no timescales were mentioned:
http://social.msdn.microsoft.com/Forums/en-US/ssdt/thread/853b8ec1-33a2-49c5-9ac2-b93d89e8b859/
Unfortunately, I understand that Gert is no longer working on SSDT, so it may no longer be in the pipeline
There's no diagramming tool within SSDT. You'll have to resort to another tool I'm afraid however that tool will (naturally) require you to deploy your SSDT project first.
A diagramming tool that builds upon the in-memory model that SSDT builds under the covers would be great. Its not there today though.
JT
I've been looking around to find the release notes for the latest releases but I couldn't find it. Anyone have a link?
Different parts of the project have different logs of the changes between versions. The most comprehensive changelog for the project is the one for the Java language bindings, and it can be found here. Other portions of the project may have their own changelogs, but they are usually limited to changes only within that part of the project. Examples include the changelogs for the .NET language bindings and for the IE driver standalone server.
Background: I developed a small .NET 3.5 WPF application that connects to an Oracle 9i database. Thinking that the ODP.NET version had to match the database, I downloaded and used an [older version][1] (9i, release 2, to be more specific) of the Oracle Data Access tools.
I'm basically done the application now and need to deploy it. Then I looked at the deployment story for ODP.NET, thinking it would be included as a prerequisite by ClickOnce and I wouldn't have to do anything. Lesson. Learned.
Everything I've read about deployment for ODP.NET talks about using XCOPY with a newer version of the Oracle tools than what I have used to this point. Not much is actually said about 9i in the documentation I've read to this point.
So what should I do?
Thanks for the help!
Here is a similar post where the answer was to change to use a 3rd party library:
ODP.NET and ClickOnce possible?
I think you area in trouble as changing libraries may involve you doing a full retest of your application - this may of course be easier done than said if it is a small app or you have good automated test coverage. Of course it depends how many computers you are deploying to. Personally I would be more inclined to stick with oracle odp and move to the latest version. If you deploy odp "the hard way" you still get the benefit of click once for future redeployments.
I've been facing a deployment problem.I've built a WPF application with visual studio 2008 and created an installer(msi) which works fine.But then it's pain to add automatic update to it. i've seen this article at windowsclient.net but it seems to be pretty old but could have been the perfect thing for me.Then i looked at the .Net Application updater block v2.0 which uses enterprise library june 2005 and for some reason it's not installing on my machine.
I thought i will need to use a more recent Enterprise library so i installed and compiled Enterprise 4.1(october 2008) but nothing better happened.To i decided to give a try to CLickonce deployment.After struggling with it, it was almost perfect.I realized that when i was testing the updates provided by the clickonce on my machine which is XP i didn't notice the need of having sqlite dll in the GAC. surely it was already there.I noticed it when i moved to vista that there is a problem.After checking the net i know it's impossible to add a dll to the Global Assembly Cache.
Now i'm stuck, i think i've hit a wall.Can any one share some of his experience? I'm willing to try the updater block if i can get help.
Thanks for reading this!!
(Won't fit in a comment)
Here's something helpful -- you can deploy the SQLCE dll's locally, instead of installing as a prerequisite, which makes it easier to deploy. Check out this article.
This is another useful article: how to keep your data safe from ClickOnce updates.
This will make more sense if you check out this thread. I have a post in this thread that has two links in it. One points to the ClickOnce way of handling database deployment, the other to a thread that is essentially the same as the blog article above.
First, you can't use that updater block. It was for .NET 1.1. It was marked obsolete when ClickOnce deployment was added in .NET 2.0.
You probably don't need to install that dll in the GAC. In many cases, you can just include it in the deployment, and it will find the local reference and use it. It just depends on the dll. So here's what I recommend you try:
Add the dll to your project. Set the 'build action' to 'none'. Set 'copy to local directory' as 'do not copy'.
Delete the reference in your project to that dll, and re-add it. But instead of picking it from the GAC, browse to the one you just added to your project and select it. On the reference properties, set 'copy local' to 'true'.
Now when you run it, it will access the local copy instead of looking for one in the GAC.
Like I said, this works great in some cases. It works for SQLCE and DirectX, but not for something like Infragistics. Some assemblies really do have to be installed in the GAC. The only way you will know is if you try it.
If you DO end up having to put it in the GAC, you can create an MSI to do that and deploy it as a prerequisite to the ClickOnce application. So you can still use ClickOnce for your main app.