I have a 2012 SSIS project with many connection manager defined at project level. The project also includes many packages having a reference to these connection managers. Now I want to convert my project to a deployment model but the wizard specifies that I need to remove connection managers at project which means moving the connection managers into packages.
How can I move the project level connection managers to my package?
You will need to convert the project from the Project Deployment Model to the Package Deployment Model.
From your description, you are seeing errors like this
This means you need to go into each package (sorry) and for every connection manager that indicates it's a (project) level one, you will right click and request that it be converted to a package level.
You may find yourself confused by this message if you look in the project's parameters and it shows empty, and you have only package level connections. This can happen if you ever had project connections--the XML behind the package retains the deleted information. (This is in SSDT for Visual Studio 2015.)
In that case the way to correct it is to edit the XML manually.
Back up the package! The chances for errors here are high, and a single typo can render the designer unable to show you the package.
Right-click on the package in solution explorer and select View Code.
Using Find, search for locate the Project Variables opening tag. it will look like this:<DTS:PackageParameters>
Select the tag and everything down to the end tag, which will be </DTS:PackageParameters> and delete it.
Save the file and close it.
Return to the designer and proceed with changing the deployment model as #billinkc describes above.
That should do it.
Joey
Related
I've installed Jaspersoft Studio 6.2.2 in order to edit a couple of existing Jasper reports. Unless I missed something, nowhere in Getting Started documentation do they explain the basic terms specific to this program. They do explain the generic Jasper terms (report, data adapter, field...) but, when it comes to Jaspersoft Studio, they just instruct you to launch wizards and use the defaults. That isn't optimal for me because I prefer to have my work under source control and separated by customer/client rather than having everything together in a local folder within my Windows profile. I also have the impression that they omit stuff because they assume you're familiar with Eclipse (I'm not).
Could you please provide me with a quick overview of the basic terms and some tips about how to use them to effectively organise work:
Workspace
Project
Project Folder
... and some other I might be missing?
My view:
A workspace is a group projects that share some configuration/environment. In project setting, you can use a common workspace configuration or define a project specific configuration.
In java world, e.g. you can define different JDK compatibility per workspace.
In jasper world, e.g. for Chinese projects, you can have projects that all have zh_CN default language set when executing preview. Different fonts might be used in this workspace. No need to set it up for every new project created.
Every workspace has it's own set of data adapters and JRS server connections.
I usually have sources under "Project folder", not in workspace folder. I just import a project into the workspace (do not copy).
BTW. One project can be in multiple workspaces.
I added a reference itextsharp.dll to my plugins project, when running my plugins using plugin-registration tool I get this exception:
Could not load file or assembly or one of its dependencies. The system
cannot find the file specified
I tried removing the ref and adding it again, cleaning and then adding it to my project from different places.
Is there restrictions in plugin registration tool about adding non crm dlls? why ? how to solve it?
This is not going to work - you cannot reference external assemblies from CRM plugins that are registered in database. If you want to do this, you will have to merge your external dll with your plugin assembly. You have to remember that adding assembly as reference is not automatically making your referenced assembly available for your base assembly, therefore if you register your plugin assembly in CRM, system is not going to "magically" find somewhere your external assembly (in your case - "itextsharp.dll"). If this is not Online system, you can add your assembly to GAC, or register all your assemblies on Disk instead of database (not recommended approach). If you want to register them in database, you will have to merge everything in one assembly using ILMerge for example.
You can't reference something in a plugin unless it's in the bin of the CRM.
To make it work you need to ILmerge your reference with the plugin. Install this package in your project: MSBuild.ILMerge.Task. Then build. It will work instantly. The package will merge everything in the bin after the build. So make sure every other references are marked "Copy Local = false". Otherwise, you'll have a crazy big assembly.
Finally, Microsoft released a solution for this. You can build a nupgk file and register dependent assemblies.
Here are the white paper and my post about this;
Microsoft : Microsoft White Paper
My summary: Here is the link
So, the error I'm getting when my build server builds my project is:
Package restore is disabled by default. To give consent, open the
Visual Studio Options dialog.
I'm aware of what this error means and how to resolve it. The problem is I cannot change anything on the build server - my company won't allow it. Additionally, creating an environment variable called EnableNuGetPackageRestore and setting it to true is not an option because that involves modifying the build server.
My question is: is it possible to simply check all of the NuGet packages that are part of a solution into source control so then the build server won't have any reason to go out and re-download them? If so, then perhaps you could explain why this error is still happening, when I've verified that all of the NuGet packages (.nupkg) are in the packages folder in source control:
Second Question: Forgive my ignorance, but what is the reason for the "package restore" feature? Is it to ensure that each package is up to date with the latest version of that package? It seems to me that this "feature" should be a setting that shouldn't hinder building a project on a build server. In my mind, if we want the build server to look for newer packages, then sure, do it, otherwise if I have all my packages in source control and we tell the build server somehow to NOT look for newer packages, that sounds reasonable to me.
So, my situation specifically was I downloaded the source code for the actual Nuget site (to create an internal implementation of Nuget in my company), and when I tried to deploy it, that's when I got the error above.
What I had to do was:
Delete the .nuget folder.
Within your file system (not via Visual Studio), modify the .csproj files (delete where it said <packageRestore>true</packageRestore>, as well as where it imported the project that had nuget.targets in the line - just do a "find" for "nuget.targets", and delete all lines that have an import.
Save your .csproj file changes.
Check in your changes into TFS.
Deploy your solution.
When in eclipse and you decide to share a project in a subversion repository using subclipse, can you make it create a folder structure for that project automagically somehow?
What I want is for every shared project to add this kind of structure:
/Client/Project/branches
/Client/Project/tags
/Client/Project/trunk/EclipseProject
Where Client is the name of the client, Project is the name of the actual project and EclipseProject is the name of the project as it exists in Eclipse. There may be more than one EclipseProject in this structure, in which case of course the directories doesn't have to be created.
Is this possible to do with a subclipse or am I better off writing a simple shell-script to do this? My first thought was doing a shell script since I don't mind using the terminal, but some of my collegues really don't like command line interfaces but dig Subclipse.
As far as I know, you cannot easily extend Subclipse to make it generate such a structure.
Actually, Subclipse had an issue with the GUI representation of deep structures, only fixed in the latest version 1.4.7 (05 December 2008), so there are not yet to provide any "template structure" ;) They try to represent existing folder trees right.
The only feature which does automatically create folders would be the "Create any intermediate folders that are missing" checkbox to Branch/Tag dialog, to make any missing and required parent directories as part of the transaction during a mkdir/move/copy commands.
That's about it.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.