Hy,
I put SSIS dtsx task from a server to another server.
I needed know what assemblies have to using and where are they?
Is anybody can give me some advice?
I nearby know what own dll-s, but maybe near more.
My project run, but I get watermarks when project use dll, but we paid for this.(early not watermark on other server.)
Maybe how export dlls from GAC to another server.
Related
We have a Libraries folder where we keep third-party DLLs and our own utility DLLs for all applications to reference. I want to do development against one of our utility DLLs and an application that consumes it at the same time. But if I check out the library DLL to change it for temporary local use, TFS insists on checking it out exclusively, which trips other people up. I understand the reasoning behind it doing that (hard/impossible to merge a DLL, so two people shouldn't be working on one at the same time), but I just want to mess with my local copy while I'm working on the library it represents.
I suppose I could delete my application's reference to the DLL and recreate the reference pointing to some other place, but of course this just begs for me to forget and check it in like that, which would obviously be bad. Not to mention that this is a pain in the neck.
How should I proceed in such a situation?
You are using a server workspace that does not allow editing outwith TFS. In TFS 2012 local workspaces were introduced which do not have a read only flag for files and you are free to edit at will.
You can change your existing workspace in a few clicks: http://msdn.microsoft.com/en-us/library/bb892960.aspx
You could just go into the file system and mark the file as writeable. Once you are happy the binary is good you could check it out, copy the new version of the file over and check it back in again. TFS marks binary files like this as locked for good reason, as you can't merge them in the way you can with textual content.
The best approach would be to use a NuGet repository to manage your binary dependencies, instead of relying on binaries checked into source control.
I'm attempting to use Web Deploy to Publish a Web Application.
I want Visual Studio to delete any files that no longer exist, so I've checked the "Remove additional files at destination" setting in my Publishing profile.
However, I want VS to ignore the /Content/uploads folder, as it contains contents that my users have uploaded. Naturally, the contents are different in my development site than they are in the live site.
Unfortunately, I have been unable to discover a way to make Visual Studio ignore this folder when publishing (it wants to delete all of the content, since it doesn't exist in the project).
Does anyone know of a way to exclude specific folders on the target site from being examined by Web Deploy?
I had a similar problem, wanting to keep some files in the deployment package even though they're not part of the project.
Try to create a custom MSBuild target for this, that works for me.
Here is a Getting Started MSBuild reference
Hope this helps.
All the best.
I was unable to find a suitable solution for this issue, so I've created my own:
https://pubsync.codeplex.com/
PubSync enables quick and reliable file syncing for publishing Visual Studio projects.
We have a SharePoint timer job that is deployed by WSP file. The job is installed by a SharePoint feature and its dll is placed on GAC.
Every other SharePoint customization is deploying by another WSP file which is placed on SharePoint Site's bin folder, and not on GAC.
The SharePoint timer job is executed by the service Windows SharePoint Services Timer (OWSTIMER.EXE) and hasn't any http or SharePoint context.
If the job have any external reference we have to put every referenced dll on the GAC too. However, we can't do it because the server polices don't allow GAC deployment of anything else beside the job dll...
Then, our team manually copy and paste the code that would be referenced and put it inside of the job project and build a giant unique dll. Such duplication process have caused all sort of troubles because of sometimes the code became desynchronized on inside the job. Nevertheless , duplication never is a beautiful thing to do and we know we are going straight to hell when we die because of it.
Is it possible to deploy the job without deploying its references on the gac?
Or is it possible to merge the referenced dlls inside a unique dll?
Or if everything else fails, it is possible to build the project so the referenced code is copied on the compilation time?
Thank you on advanced.
The real problem is your server admins blanket ban on GAC deployment for anything other than the job DLL. Nothing like a policy without considering the implications ;)
The band aid to this is ILMerge.
ILMerge is a utility that can be used
to merge multiple .NET assemblies into
a single assembly. ILMerge takes a set
of input assemblies and merges them
into one target assembly.
This will allow you to merge your job assembly and all the dependant assemblies into one super job assembly for deployment - much better than manually copy and pasting code. Plus you can do it in the postbuild steps so its all built into your build process.
Why can't referenced dll be put in the bin directory ? It can certainly be.
How do you debug your SharePoint 2007 code? Since SharePoint runs on a remote server, and I'm developing on a windows xp machine (with the necessary .dll files copied into my GAC), I haven't had much luck with finding easy ways to debug. Breakpoints don't work, etc.
The best way I've come up with is to enable page tracing in the web.config file, write trace messages throughout my code, and access trace.axd whenever I need to debug.
Does anyone have any better suggestions for debugging? Am I missing something?
From Andrew Connell's blog post on the subject:
Attaching the debugger to GAC'd
assemblies: "Why aren't my breakpoints
being hit?!?!" Ever been there? Me
too... what a PITA that is! What's
going on? Well, the assemblies are in
the GAC and the Visual Studio debugger
can't see the debugging symbols (aka:
*.pdb). Unless you've gone through the trouble of setting up a symbol store
where all your PDBs are going, you'll
need to put the debugging symbols in
the same location as the assembly. The
trick is finding the folder that
contains your DLL in the GAC.
The c:\windows\assembly folder is not
a real folder, it's a virtual folder.
To get to the REAL folder, do the
following:
Start ยป Run
%systemroot%\assembly\gac
[ENTER]
This will open the GAC folder.
Now, poke around until you find a
folder that looks like this (you might
need to jump up one folder and dive
into the MSIL folder): [assembly file
name -.DLL extention][assembly
version in format of
> #.#.#.#]__[assembly public key token].
When you find that folder, open it up
and you'll see your assembly. Copy the
PDB file to that folder and then
attach the debugger for some debugging
joy!
The best way (even the one endorsed by Microsoft) is to have a Windows 2003 Server with Sharepoint as your local Development machine.
See also this topic.
Don't put your assemblies into the GAC, put them in the bin directory - then you can use the VS remote debugger. Google creating .WSP files for distribution.
This also has the advantage that its easier to copy your new builds onto the server after compilation (post-build step) and its also the recommended way to increase security.
I recommend you develop on a Windows 2003 server with Sharepoint. It's a hassle to debug on a remote server.
You can do it in a virtual machine with VMWare or Virtual PC, if you have XP on your workstation.
Virtual machine is the only way to go. You don't want to dedicate a whole machine to dev (unless you have extras) and developing on your production server is just asking for trouble. I prefer VMWare, but there are others that work just as well.
Tracing works well as normal debugging isn't really an option.
What else I do is try to develop all the logic (the stuff that isn't SharePoint dependent) on just a regular asp.net site, then integrate it into SharePoint after it's tested.
Hope that makes sense.
Are you talking about developing web parts? Custom pages? Something else?
I'm looking for something that can copy (preferably only changed) files from a development machine to a staging machine and finally to a set of production machines.
A "what if" mode would be nice as would the capability to "rollback" the last deployment. Database migrations aren't a necessary feature.
UPDATE: A free/low-cost tool would be great, but cost isn't the only concern. A tool that could actually manage deployment from one environment to the next (dev->staging->production instead of from a development machine to each environment) would also be ideal.
The other big nice-to-have is the ability to only copy changed files - some of our older sites contain hundreds of .asp files.
#Sean Carpenter can you tell us a little more about your environment? Should the solution be free? simple?
I find robocopy to be pretty slick for this sort of thing. Wrap in up in a batch file and you are good to go. It's a glorified xcopy, but deploying my website isn't really hard. Just copy out the files.
As far as rollbacks... You are using source control right? Just pull the old source out of there. Or, in your batch file, ALSO copy the deployment to another folder called website yyyy.mm.dd so you have a lovely folder ready to go in an emergency.
look at the for command for details on how to get the parts of the date.
robocopy.exe
for /?
Yeah, it's a total "hack" but it moves the files nicely.
For some scenarios I used a freeware product called SyncBack (Download here).
It provides complex, multi-step file synchronization (filesystem or FTP etc., compression etc.). The program has a nice graphical user interface. You can define profiles and group/execute them together.
You can set filter on file types, names etc. and execute commands/programs after the job execution. There is also a job log provided as html report, which can be sent as email to you if you schedule the job.
There is also a professional version of the software, but for common tasks the freeware should do fine.
You don't specify if you are using Visual Studio .NET, but there are a few built-in tools in Visual Studio 2005 and 2008:
Copy Website tool -- basically a visual synchronization tool, it highlights files and lets you copy from one to the other. Manual, built into Visual Studio.
aspnet_compiler.exe -- lets you precompile websites.
Of course you can create a web deployment package and deploy as an MSI as well.
I have used a combination of Cruise Control.NET, nant and MSBuild to compile, and swap out configuration files for specific environments and copy the files to a build output directory. Then we had another nant script to do the file copying (and run database scripts if necessary).
For a rollback, we would save all prior deployments, so theoretically rolling back just involved redeploying the last working build (and restoring the database).
We used UnleashIt (unfortunate name I know) which was nicely customizable and allowed you to save profiles for deploying to different servers. It also has a "backup" feature which will backup your production files before deployment so rollback should be pretty easy.
I've given up trying to find a good free product that works.
I then found Microsoft's Sync Toy 2.0 which while lacking in options works well.
BUT I need to deploy to a remote server.
Since I connect with terminal services I realized I can select my local hard drive when I connect and then in explorer on the remote server i can open \\tsclient\S\MyWebsite on the remote server.
I then use synctoy with that path and synchronize it with my server. Seems to work pretty well and fast so far...
Maybe rsync plus some custom scripts will do the trick.
Try repliweb. It handles full rollback to previous versions of files. I've used it whilst working for a client who demanded its use and I;ve become a big fan of it, partiularily:
Rollback to previous versions of code
Authentication and rules for different user roles
Deploy to multiple environments
Full reporting to the user via email / logs statiing what has changed, what the current version is etc.